decline and fall of modperl?

Hi and sorry for the provocative title of my post :)

One of our customers is doing a detailed review of a mason/modperl ERP
app we've built for them since 2001. Prodded by some buzzword-compliant
consultants they are expressing concerns that the app's underlying
technologies - perl, modperl and mason - are becoming obsolete. They
feel that a web application framework must have 'rails' or some other
buzzword in its name.

But their main argument is that perl is declining as a web developement
language. Also they rightly feel that competent perl developers are
becoming harder to find.

What arguements could I use to address these concerns and convince them
that their initial investement in perl is still safe and won't be
obsolete in 10 years?

The client's local developers (who maintain the app we've built) feel
that mason gives too much freedom to write messy code and badly
structure a web app.

Indeed mason has very little constraints, maybe just slightly more than
straight modperl. So it requires experienced, self-disciplined devs,
which are few and far between.

So my second question is, what perl web development framework should we
recommend to our client? Catalyst looks like a winner, but maybe there
are others?

Thanks for your insights,

Re: decline and fall of modperl?

On Mon, Mar 23, 2009 at 9:07 AM, Louis-David Mitterrand
wrote:
> One of our customers is doing a detailed review of a mason/modperl ERP
> app we've built for them since 2001. Prodded by some buzzword-compliant
> consultants they are expressing concerns that the app's underlying
> technologies - perl, modperl and mason - are becoming obsolete. They
> feel that a web application framework must have 'rails' or some other
> buzzword in its name.

I believe that the right developers can make good sites with Rails,
but Ruby is a risky choice compared to Perl. It has a much smaller
base of developers and hasn't been used for any large websites except
the notoriously unreliable twitter.com.

> But their main argument is that perl is declining as a web developement
> language. Also they rightly feel that competent perl developers are
> becoming harder to find.

http://blog.timbunce.org/2008/03/08/perl-myths/

> What arguements could I use to address these concerns and convince them
> that their initial investement in perl is still safe and won't be
> obsolete in 10 years?

Probably none if they've already made up their minds, as it sounds
like they have. You might find out why they don't write it themselves
if they know so much about the future of software development tools.

> The client's local developers (who maintain the app we've built) feel
> that mason gives too much freedom to write messy code and badly
> structure a web app.

It gives a lot of freedom, and if you have reckless developers and/or
no development standards, you will end up with bad code.

> So my second question is, what perl web development framework should we
> recommend to our client?

If you want to use Mason, you might mention to them that Amazon.com
uses it for all of their pages and they don't seem to have gone under
yet. But really, this is a marketing decision. Using another
framework won't prevent people from writing bad code. Only good dev
practices can do that.

- Perrin

Re: decline and fall of modperl?

> On Mon, Mar 23, 2009 at 9:07 AM, Louis-David Mitterrand
> wrote:
>> One of our customers is doing a detailed review of a mason/modperl ERP
>> app we've built for them since 2001. Prodded by some buzzword-compliant
>> consultants they are expressing concerns that the app's underlying
>> technologies - perl, modperl and mason - are becoming obsolete. They
>> feel that a web application framework must have 'rails' or some other
>> buzzword in its name.
>
> I believe that the right developers can make good sites with Rails,
> but Ruby is a risky choice compared to Perl. It has a much smaller
> base of developers and hasn't been used for any large websites except
> the notoriously unreliable twitter.com.

RoR is very good for simple web apps, and most web apps start as simple
apps, but it is much more difficult to develop an application made with RoR
if you'll need it to do complicated things.

>> But their main argument is that perl is declining as a web developement
>> language. Also they rightly feel that competent perl developers are
>> becoming harder to find.

This is true. Less and less programmers use perl, and in most parts of the
world it is hard to find competent perl programmers.
I know that this could be finally the most important point for a company
owner, because he might don't care which of the language is better if he
would need to pay more for finding programmers, or can't find at all.

>> What arguements could I use to address these concerns and convince them
>> that their initial investement in perl is still safe and won't be
>> obsolete in 10 years?

There are fewer and fewer perl programmers because perl is not promoted by a
company like 37 Signals, or Zend, or Sun, or Microsoft, and there are
already some very well written books for teaching perl, so the perl
programmers don't need other books to learn perl basics, so the editors
don't like that, and unfortunately almost all the perl books that teach
about how to create a web app teach about the old CGI style which is not a
good style anymore.

A new perl programmer doesn't know what he should do to make a good
application in perl, because there are no books that helps him to decide
what framework or perl modules to choose, so he doesn't know if the best
solution is Catalyst framework, or CGI::Application, or Mason, or Gantry or
another framework, he doesn't know if the templating system he should start
learning is Template-Toolkit, or HTML::Template, or Mason, or something
else, or if he should use an ORM like DBIx::Class, or Rose::DB or better use
just DBI. When a new perl programmer will want to learn to use the OOP style
of programming, there would be no book to tell him to use Moose or Mouse,
but he will be taught only to use the old style and there could be many such
examples.

So the programmer would be surely confused, and prefer to use a unique-style
language like Python or Ruby, but this doesn't matter that they are better.
Maybe Python is better than Perl for creating desktop apps and interacting
with the OS, especially under Windows, but not for creating web apps.

When the beginners compare the languages, they compare what the installation
packages offer them, but well.... perl doesn't offer too much. Perl is good
if we consider many other good-written modules that can be found on CPAN.

Some advantages of perl are:
- Catalyst framework is much better than the frameworks that can be used in
Python, Ruby and PHP, and it has very many advantages from the flexibility
of the dispatcher, the ease of use (even though it might not be easy to
learn it), the possibility of using more templating systems, more ORMS, more
form processors, more type of authentication/authorization modules..
- Although it might not be so elegant, Mason offers a very high flexibility
for creating templates.
- DBIx::Class ORM offers very many features and it can work very well with
Catalyst, and HTML::FormFu form processor.
- There are more form processors that can be used in a perl project, and
some of them create even the Javascript code used for client side
validation.
- There are modules that can be used for including JS widgets that use AJAX
in a perl app, some of them don't even require to know Javascript.
- There are more modules that can be used for creating custom wikis included
in an app.
- Even Movable Type app for blogging is made in perl, and from I've recently
seen from a matrix that compares the blog apps, it is much better than
WordPress.

>> So my second question is, what perl web development framework should we
>> recommend to our client?

I found that Catalyst framework creates a much more elegant web app than
Mason. Of course, if the developer insists, he can create bad code with any
language or any framework.

Octavian

Re: decline and fall of modperl?

On Mon, Mar 23, 2009 at 11:30 AM, Octavian R=E2snita w=
rote:
> This is true. Less and less programmers use perl, and in most parts of th=
e
> world it is hard to find competent perl programmers.

Unless you have some evidence of this, stop spreading FUD. The job
listings for Perl are strong. They're huge compared to those for
Ruby. Of course Java is massively more popular than either of them,
but that doesn't make the perl market small.

> So the programmer would be surely confused, and prefer to use a unique-st=
yle
> language like Python or Ruby, but this doesn't matter that they are bette=
r.

Python has tons of web frameworks, ORMs, and templating languages too.
Java has even more. The only language that has only one significant
web framework is Ruby.

- Perrin

Re: decline and fall of modperl?

On Monday, 2009-03-23 at 11:55:46 -0400, Perrin Harkins wrote:
> On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita wrote:
> > This is true. Less and less programmers use perl, and in most parts of the
> > world it is hard to find competent perl programmers.

> Unless you have some evidence of this, stop spreading FUD. The job
> listings for Perl are strong. They're huge compared to those for
> Ruby. Of course Java is massively more popular than either of them,
> but that doesn't make the perl market small.

Figures from the German freelancer market, Gulp (www.gulp.de):
CVs (called profiles, a total of 60823 are available) with:

Perl 5470
Ruby 234
Java 11261

About two Java programmers perl Perl programmer. About 23 Perl
programmers per Ruby programmer. (Germans are known to be
conservative...)

Projects (total 1317) mentioning

Perl 54
Ruby 4
Java 153

The programmer-to-project ratios are:

Perl 101
Ruby 58
Java 73

So, yes, Perl is a bad choice. It is the language with the most
competition. Go for Ruby! There may be only four projetcs, but you have
less competition to fear! :-)

Lupe Christoph
--
| There is no substitute for bad design except worse design. |
| /me |

Re: decline and fall of modperl?

Louis-David Mitterrand wrote:
> Hi and sorry for the provocative title of my post :)
>
What better way to get a response?

What you have is better than what you don't, so sticking with a tech you
already have is often the most pragmatic path.

I agree with the others, in that if the company hires a good programmer,
they will get good code out.

In the end, all I really want to add to what people have said is this:

Perl has been relatively static for a long time, without many changes.
The new version of perl in the works is going to change that. I fully
expect perl to become far more interesting to the programming community
with that upgrade. Perl will move from the old one to the latest one,
and then it WILL be a buzzword again.

Least, thats what I think.

David

Re: decline and fall of modperl?

From: "David Ihnen"
> The new version of perl in the works is going to change that. I fully
> expect perl to become far more interesting to the programming community
> with that upgrade. Perl will move from the old one to the latest one, and
> then it WILL be a buzzword again.
>
> Least, thats what I think.

That's what I also hope, but I don't think it will happen too soon.

PHP, C#, Java are much more prefered, because the programs created with them
can hide the source code much better, while this is not possible with Perl.
This is a big reason why the software companies that create custom programs
for their clients prefer to use those languages and not perl. Not because
perl is bad.
I hope Perl 6 will also solve this issue...

Octavian

Re: decline and fall of modperl?

It amazes me that this entire thread neglects to mention PHP. Granted, =20=

it started with a discussion about web frameworks, for which PHP does =20=

not have a strong footing, unless of course you count Drupal and =20
Wordpress and the like among such "frameworks." But still, PHP cannot =20=

and should not be ignored.

In my experience in working on Movable Type, PHP is the single biggest =20=

source of competition on the market because it has the lowest barrier =20=

to entry and has the largest mind share. Say what you will about PHP =20
developers, but they are a dime a dozen these days and they are about =20=

as ubiquitous as HTML/CSS developers.

We were frequently confronted with this question/challenge by MT =20
customers: "we can't find *affordable* Perl developers to help us," or =20=

worse, "we already have 10 people on staff who know PHP." What it =20
boils down to for most companies is "can I develop this thing with the =20=

staff I have, or do I have to open up job reqs to get the talent I =20
need?" or put simple, "how much is this going to cost me?"

Put into these terms, PHP always looks cheaper on paper because =20
chances are there are people on staff who already know PHP, or the =20
cost of hiring a good Perl programmer is too high.

Byrne



On Mar 23, 2009, at 10:05 AM, Lupe Christoph wrote:

> On Monday, 2009-03-23 at 11:55:46 -0400, Perrin Harkins wrote:
>> On Mon, Mar 23, 2009 at 11:30 AM, Octavian R=E2snita =
>> > wrote:
>>> This is true. Less and less programmers use perl, and in most =20
>>> parts of the
>>> world it is hard to find competent perl programmers.
>
>> Unless you have some evidence of this, stop spreading FUD. The job
>> listings for Perl are strong. They're huge compared to those for
>> Ruby. Of course Java is massively more popular than either of them,
>> but that doesn't make the perl market small.
>
> Figures from the German freelancer market, Gulp (www.gulp.de):
> CVs (called profiles, a total of 60823 are available) with:
>
> Perl 5470
> Ruby 234
> Java 11261
>
> About two Java programmers perl Perl programmer. About 23 Perl
> programmers per Ruby programmer. (Germans are known to be
> conservative...)
>
> Projects (total 1317) mentioning
>
> Perl 54
> Ruby 4
> Java 153
>
> The programmer-to-project ratios are:
>
> Perl 101
> Ruby 58
> Java 73
>
> So, yes, Perl is a bad choice. It is the language with the most
> competition. Go for Ruby! There may be only four projetcs, but you =20
> have
> less competition to fear! :-)
>
> Lupe Christoph
> --=20
> | There is no substitute for bad design except worse =20
> design. |
> | /=20
> me=20
> =
|

Re: decline and fall of modperl?

On Monday, 2009-03-23 at 10:54:59 -0700, Byrne Reese wrote:
> It amazes me that this entire thread neglects to mention PHP.

OK, I'll add PHP...

Figures from the German freelancer market, Gulp (www.gulp.de):
CVs (called profiles, a total of 60823 are available) with:

Perl 5470
Ruby 234
Java 11261
PHP 6047

About two Java programmers per Perl programmer. About 23 Perl
programmers per Ruby programmer. (Germans are known to be
conservative...) Roughly the same number of PHP people as Perl people.

Projects (total 1317) mentioning

Perl 54
Ruby 4
Java 153
PHP 34

The programmer-to-project ratios are:

Perl 101
Ruby 58
Java 73
PHP 178

So, yes, Perl is a bad choice. It is the language with the most
competition. Go for Ruby! There may be only four projetcs, but you
have less competition to fear! :-) And you should avoid PHP, too.

Turns out, the numbers for PHP aren't that different from those for
Perl. I have to admit that I'm surprised. By the dearth of PHP projects
as well as the number of PHP people.

Lupe Christoph
--
| There is no substitute for bad design except worse design. |
| /me |

Re: decline and fall of modperl?

Alright, I don't want to quibble, but I would question any conclusions
you can draw from the numbers based upon the sole fact that it is
based upon how developer self-identify.

I know that Wordpress and Drupal freelancers do not position
themselves as PHP programmers, but rather WordPress and Drupal
programmers. The same may very well be true for Plone, Movable Type
and any number of reputable application and CMS frameworks on the
market - where much of web development is happening these days.

Who knows maybe we are talking about two different things.

Byrne

On Mar 23, 2009, at 11:32 AM, Lupe Christoph wrote:

> On Monday, 2009-03-23 at 10:54:59 -0700, Byrne Reese wrote:
>> It amazes me that this entire thread neglects to mention PHP.
>
> OK, I'll add PHP...
>
> Figures from the German freelancer market, Gulp (www.gulp.de):
> CVs (called profiles, a total of 60823 are available) with:
>
> Perl 5470
> Ruby 234
> Java 11261
> PHP 6047
>
> About two Java programmers per Perl programmer. About 23 Perl
> programmers per Ruby programmer. (Germans are known to be
> conservative...) Roughly the same number of PHP people as Perl people.
>
> Projects (total 1317) mentioning
>
> Perl 54
> Ruby 4
> Java 153
> PHP 34
>
> The programmer-to-project ratios are:
>
> Perl 101
> Ruby 58
> Java 73
> PHP 178
>
> So, yes, Perl is a bad choice. It is the language with the most
> competition. Go for Ruby! There may be only four projetcs, but you
> have less competition to fear! :-) And you should avoid PHP, too.
>
> Turns out, the numbers for PHP aren't that different from those for
> Perl. I have to admit that I'm surprised. By the dearth of PHP
> projects
> as well as the number of PHP people.
>
> Lupe Christoph
> --
> | There is no substitute for bad design except worse
> design. |
> | /
> me
> |

Re: decline and fall of modperl?

From: "Byrne Reese" It amazes me that this entire
thread neglects to mention PHP. Granted,
> it started with a discussion about web frameworks, for which PHP does not
> have a strong footing, unless of course you count Drupal and Wordpress
> and the like among such "frameworks." But still, PHP cannot and should
> not be ignored.

Well, Drupal is not a framework but a CMS, and WordPress is a kind of CMS
used for creating blogs.

I have tested more PHP frameworks but most of them really sucks. I think
that CodeIgniter was the one I liked the most, but it is still very far
behind Catalyst.
The ORM it uses is not so advanced as DBIx::Class, and it doesn't allow
using other ORMS, it doesn't have features for using more templating systems
easy, it has a strange and hard to use form processor, the URL dispatching
is more limited and harder to use...

> In my experience in working on Movable Type, PHP is the single biggest
> source of competition on the market because it has the lowest barrier to
> entry and has the largest mind share. Say what you will about PHP
> developers, but they are a dime a dozen these days and they are about as
> ubiquitous as HTML/CSS developers.

That's true, but Perl programmers, especially those who create advanced
programs don't usually compete with those PHP programmers you are talking
about.
Perl still has some big issues if we want it to compete with PHP for that
kind of programs that can be easily installed on servers that offer web
hosting for free or for 3 dollars a month, because CPAN modules are not
built in the Perl package and are harder to install, or impossible to
install without root and shell access.

The problem is that maybe 99% of the web sites are that kind of web sites
that don't have their own server, or VPS, but use shared hosting, and less
and less free web hosting servers offer support for Perl because it can't be
really used anyway.

> We were frequently confronted with this question/challenge by MT
> customers: "we can't find *affordable* Perl developers to help us," or
> worse, "we already have 10 people on staff who know PHP." What it boils
> down to for most companies is "can I develop this thing with the staff I
> have, or do I have to open up job reqs to get the talent I need?" or put
> simple, "how much is this going to cost me?"
>
> Put into these terms, PHP always looks cheaper on paper because chances
> are there are people on staff who already know PHP, or the cost of hiring
> a good Perl programmer is too high.
>
> Byrne

For most of the web sites, this is very true.
If somebody who wants to make a web site that will be hosted on a share
hosting server for 5 dollars a month comes to me and asks me how much I ask
for making his web site, I can tell him that I can't make that web site
because I can't install a Perl framework on that server, I can't install
other perl modules I might need, and if he wants me to create the site for
him, he should pay 30 or 40 dollars per month for a VPS. Well, in that case
only this will mean too much, before telling him how much it costs.

A PHP programmer even if he wants to use a framework on a free hosting web
site, he could do it because he might find frameworks that can be installed
by just unarchiving a file, so even if that framework won't be as good as
Catalyst, it would be surely much better than what I can install on that
server.

So... Perl programmers target only bigger businesses and more important web
sites and this is a reason why the statistics are not very relevant.
If a site like Amazon uses Perl, it is just one web site, but it has a
traffic like a few thousands other small web sites.

The problem is that there are no very many big sites that use perl either.
I knew that Amazon used Perl, than tried to use Java, than... I don't know
what they use now.
Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and Sun
probably uses Java.

I don't know other important sites that use Perl.
Even on www.perl.com, the link "Perl success stories" wasn't updated and
points to an O'Reilly web page that advertises some perl books.
There is a "Perl success stories" on O'Reilly's web site, but somewhere
else, and those success stories seem to be pretty old, much before the so
called Web 2.0 era.

If I'd need to compare Perl with a company, I'd say that his technical
department is very disorganized, but that it has the best results, however
its marketing and financial departments are dead. And by the way, this
company doesn't really follow the new standards that other companies use.
(And I am talking about the web services which aren't really compatible with
those offered by DotNet and Java, about the dot notation for separating
classes and objects, and even about the dollars and @, % signs that might
seem strange in these days because other languages don't use them.)

Octavian

Re: decline and fall of modperl?

Hire Dave Rolsky (who wrote the Mason book, and maintains HTML-Mason),
he's apparently looking for work:

http://blog.urth.org/2009/03/need-a-programmer.html

You'll be hard pressed to find anyone more competent, but he might want
to re-implement the whole system, you never know...

Adam

Re: decline and fall of modperl?

> The problem is that there are no very many big sites that use perl
> either.
> I knew that Amazon used Perl, than tried to use Java, than... I
> don't know what they use now.
> Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet
> and Sun probably uses Java.

I will add:

* LiveJournal
* TypePad
* Vox
* Popular MT sites like:
- Huffington Post
- Gothamist
- Talking Points Memo
- many, many, many more of course

Re: decline and fall of modperl?

> Alright, I don't want to quibble, but I would question any conclusions
> you can draw from the numbers based upon the sole fact that it is
> based upon how developer self-identify.
>
Every language has it's own sub-languages or frameworks that they identify
themselves as. So I suspect the statistics Lupe posted are OK on average
and reflecting the general reality and representation of job availability.

Adding onto what Lupe has posted, I can confirm my own quick search on
www.monster.com (nationwide). Keywords: Perl, PHP, Java, Ruby yield the
following as of 5 minutes ago.

Perl (1795), PHP (1145), Java (4940), and Ruby (318)

If you wish to add Drupal or other keywords, you may want to consider
doing so rather than leaving open speculation. If PHP is a skill needed
for the job, I suspect it will appear *somewhere* in the job description.
If you search Drupal on monster.com for example you will see a lot of PHP
overlap.

Addressing some other themes I've seen here (not a direct response to you)

- Perl has been around a long time without much change

I am not sure why anyone thinks that is a bad thing. The fact that it is a
stable language seems 'good' to me. It hasn't changed because it does it's
job really well for what it does.

- That the amount of tools that exist for Perl are 'confusing'

I am not sure that is the case. The # of tools that exist does offer
choice and it can be a bit difficult to weed through the bad stuff to get
to the more useful tools, but that's what a mailing list like this can
help with. Someone can easily post saying "I need something to do X Y and
Z and I am interested in the underlying power of mod-perl or perl, can you
guys help me" and there's always posts where people do help guide.

Still though, it's not like it's really that hard. People here on the
mailing list like Perrin have written up talks comparing different
toolkits which can inform the community as well.

And even without those resources, if you are used to working with open
source tools you can usually visit and website and within 5 minutes figure
out if it's active and booming community or a dead horse.

So I see little problem really. In fact, the choice is a great thing.

As Perrin I think said earlier (I'm paraphrasing liberally I suspect), if
a company has already made up their mind ahead of time to use or not use a
technology, it's pretty easy to bash whatever you want.

That's why I liked Lupe's statistics on German job market, and I can back
up the ratios of jobs with the USA www.monster.com website which makes me
comfortable that his #s are probably reasonable representation of job
market reality without FUD getting in the way.

Best regards,
Gunther

Re: decline and fall of modperl?

On Mon, Mar 23, 2009 at 3:07 PM, Octavian R=E2snita wr=
ote:
> I knew that Amazon used Perl, than tried to use Java, than... I don't kno=
w
> what they use now.

Please stop with the FUD! Amazon uses Perl for their front-end
development. Check their job ads.

> Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and Su=
n
> probably uses Java.

Yahoo uses plenty of Perl on their back-end, and PHP for their
front-end pages. TicketMaster is Perl. IMDB is Perl. LiveJournal is
Perl. No one cares what Sun and Microsoft run on their websites.

The original poster asked for help winning a contract that he wants to
use Perl for. So far, you're not contributing.

- Perrin

Re: decline and fall of modperl?

On Mon, 23 Mar 2009 15:16:59 -0400, Byrne Reese
wrote:

> I will add:
>
> * LiveJournal
> * TypePad
> * Vox
> * Popular MT sites like:
> - Huffington Post
> - Gothamist
> - Talking Points Memo
> - many, many, many more of course

Let's not forget ticketmaster... of which many mod_perl developers have
worked for.

Re: decline and fall of modperl?

Hi.

It possible to encrypt perl sources with same safety as with PHP -
with possibility of source decryption. But Perl developers are in
general more advanced than PHP developers so they know how to decrypt
it, in contrast to PHP developers that do not know that encrypted PHP
sources can easily be decrypted. There are also some bytecode
compilers for Perl (alpha stage).

2009/3/23 Octavian R=E2snita :

> PHP, C#, Java are much more prefered, because the programs created with t=
hem
> can hide the source code much better, while this is not possible with Per=
l.
> This is a big reason why the software companies that create custom progra=
ms
> for their clients prefer to use those languages and not perl. Not because
> perl is bad.

--=20
Alexandr Ciornii, http://chorny.net

Re: decline and fall of modperl?

--000e0cd487bafbefe20465ced34c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I believe Craigslist and Slashdot are both entirely done in perl/mod_perl.




On Mon, Mar 23, 2009 at 2:49 PM, Dan Stephenson wrote:

> On Mon, 23 Mar 2009 15:16:59 -0400, Byrne Reese
> wrote:
>
> I will add:
>>
>> * LiveJournal
>> * TypePad
>> * Vox
>> * Popular MT sites like:
>> - Huffington Post
>> - Gothamist
>> - Talking Points Memo
>> - many, many, many more of course
>>
>
> Let's not forget ticketmaster... of which many mod_perl developers have
> worked for.
>

--000e0cd487bafbefe20465ced34c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I believe Craigslist and Slashdot are both entirely done in perl/mod_pe=
rl.

Re: decline and fall of modperl?

From: "Byrne Reese"
>> The problem is that there are no very many big sites that use perl
>> either.
>> I knew that Amazon used Perl, than tried to use Java, than... I don't
>> know what they use now.
>> Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet and
>> Sun probably uses Java.
>
> I will add:
>
> * LiveJournal
> * TypePad
> * Vox
> * Popular MT sites like:
> - Huffington Post
> - Gothamist
> - Talking Points Memo
> - many, many, many more of course

Do you know other sites that don't use Movable Type? :-)

But even if we talk about Movable Type... I've seen that WordPress is known
much better than MovableType. Gues why. MovableType has much more features
than WordPress, however WordPress is better known. Maybe because there are
much much more interface translations for WordPress than for MovableType, or
maybe because it uses PHP and there are much more PHP programmers.

If I need to choose 2 wikis, or 2 programs that can be used for creating
blogs, I would choose one made in Perl, because I use perl, even though I
know that I would probably just use that program and don't make any change
in it.

MovableType is a big success of Perl. Too bad that there is no program for
creating wikis that has the same success.
(I've tried TWiki and I found that even though it has many features, it has
too much bugs, so finally I started to use MediaWiki which is much better,
but unfortunately it is not made in perl. I hope MovableType doesn't have
the same issues.)

Octavian

Re: decline and fall of modperl?

From: "Perrin Harkins"
> The original poster asked for help winning a contract that he wants to
> use Perl for. So far, you're not contributing.
> - Perrin

I presented more advantages of perl, in one of my previous message so I
contributed, but I don't like to hear that Perl is everywhere and hear about
a lot of statistics that shows that it is much more used than PHP while I
see that most of the web sites are made with PHP and most of the new
programmers become interested in Python not in Perl.

Octavian

Re: decline and fall of modperl?

From: "Alexandr Ciornii"
> Hi.
>
> It possible to encrypt perl sources with same safety as with PHP -
> with possibility of source decryption. But Perl developers are in
> general more advanced than PHP developers so they know how to decrypt
> it, in contrast to PHP developers that do not know that encrypted PHP

I heard this theory for more times but nobody was able to give an example.

Can you re-create the clear PHP source code from an encoded PHP file that
was encoded with ZendEncoder?
Can you give an example of a program or module that can do the same type of
encryption for perl?

> sources can easily be decrypted. There are also some bytecode
> compilers for Perl (alpha stage).

Alpha stage means something useless for the present time.

Can I encrypt some .pm modules in such a way that they couldn't be decrypted
easier than the PHP files encrypted by Zend Encoder?
If yes, please tell us how, because it would be a really important
information for the perl developers.

Octavian

Re: decline and fall of modperl?

At 11:34 PM +0200 3/23/09, Octavian R=E2snita wrote:
>From: "Byrne Reese"
>>>The problem is that there are no very many big sites that use perl either=

>>>I knew that Amazon used Perl, than tried to=20
>>>use Java, than... I don't know what they use=20
>>>now.
>>>Google uses Python, Yahoo uses PHP, Microsoft=20
>>>probably uses DotNet and Sun probably uses=20
>>>Java.
>>
>>I will add:
>>
>>* LiveJournal
>>* TypePad
>>* Vox
>>* Popular MT sites like:
>> - Huffington Post
>> - Gothamist
>> - Talking Points Memo
>> - many, many, many more of course
>
>Do you know other sites that don't use Movable Type? :-)

http://www.booking.com
http://www.hospitalitynet.org



Liz

Re: decline and fall of modperl?

> Do you know other sites that don't use Movable Type? :-)

Not as extensively. :)

> But even if we talk about Movable Type... I've seen that WordPress
> is known much better than MovableType. Gues why. MovableType has
> much more features than WordPress, however WordPress is better
> known. Maybe because there are much much more interface translations
> for WordPress than for MovableType, or maybe because it uses PHP and
> there are much more PHP programmers.

I won't belabor this thread with a competitive analysis of WordPress'
mindshare over MT as the answer to that question is multifaceted. But
I will say that the fact that WP is written in PHP has A LOT to do
with it. It also has an incredibly liberal commit/patch policy,
lending to both the speed of its advancement and negatively to its
security; but most importantly to its success in recruiting new
developers to the platform.

> MovableType is a big success of Perl.

That is great to hear. I am working on a project hopefully that will
get the folks from this community perhaps more actively engaged in the
development and advancement of MT. I am very proud of MT and remain
committed to its success.

Byrne

Re: decline and fall of modperl?

Byrne Reese wrote:
>> The problem is that there are no very many big sites that use perl
>> either.
>> I knew that Amazon used Perl, than tried to use Java, than... I don't
>> know what they use now.
>> Google uses Python, Yahoo uses PHP, Microsoft probably uses DotNet
>> and Sun probably uses Java.
>
> I will add:
>
> * LiveJournal
> * TypePad
> * Vox
> * Popular MT sites like:
> - Huffington Post
> - Gothamist
> - Talking Points Memo
> - many, many, many more of course
>
As far as I know, these sites also use Perl or mod_perl:

o Internet Movie Database (Amazon)
o TicketMaster (last I checked, but that was a couple of years ago and
they were recently sold or bought or something)
o CitySearch.com
o ArtToday.com
o PBS Online

I also know that a very large international cosmetics company uses
mod_perl quite extensively. I've done some work for them and I don't
know if or how they would care for their name being mentioned here, so I
won't, but... If you want "large" -- they define "large."

-----
I wouldn't "count" a company that uses a Perl "product" or CMS or some
sort (such as MT) as a "perl site" in the strict sense of the word.
Some of the techies at places like Huffington Post may be aware of the
underlying technology, but I doubt very much that "Perl" itself drove
the decision as much as the great work that Ben and Mena Trott did at
SixApart.com in creating such a product.

-----
And I have to chime in and say I've seen plenty of ugly, ridiculous code
written in every language imaginable (everyone's precious "Java" and JEE
very much included.) It's not a product of the language as much as the
language bearer. Sorry. That's always been the case. Margin for error
on a tight mountain road doesn't automatically a bad driver make -- only
the one who will not heed the type of road and car he's in in the
situation. Anyone can zoom through an intersection full of traffic on a
wide-open, flat country road as well. The road being the intent and
direction and the car being Perl (and pretty cotton-pickin' good one, I
might add), I don't see the correlation here. Again, this is clever
smoke and mirrors by consultants with a different agenda and product to
sell. The craft of programming and development are only slightly
impacted by these kinds of things.

-pj

Re: decline and fall of modperl?

This is a multi-part message in MIME format.
--------------000906040602070708060706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Alexandr Ciornii wrote:
> Hi.
>
> It possible to encrypt perl sources with same safety as with PHP -
> with possibility of source decryption. But Perl developers are in
> general more advanced than PHP developers so they know how to decrypt
> it, in contrast to PHP developers that do not know that encrypted PHP
> sources can easily be decrypted. There are also some bytecode
> compilers for Perl (alpha stage).
>
> 2009/3/23 Octavian Râsnita :
>
>
>> PHP, C#, Java are much more prefered, because the programs created with them
>> can hide the source code much better, while this is not possible with Perl.
>> This is a big reason why the software companies that create custom programs
>> for their clients prefer to use those languages and not perl. Not because
>> perl is bad.
>>
>
>
Not to keep the PHP thing going, but I would tend to de-classify about
30% of the people who call themselves "PHP developers." There is a VERY
high propensity among many in this community to go out and "borrow code"
and "retrofit it." I'm not saying Perl developers don't do this, but I
don't believe there are very many heavily invested in the Perl community
who have this bent -- many are devoted to the craft of true, honest to
goodness OO development.

I also left out a very important and I would say very well known Perl
*powerhouse* in corporate America:

WhitePages.com

Some of the best of the best work there. You can't even get a sniff
from them (eg. interview) without being in the upper crust of Perl
development. No Perl "wanna-bes" allowed there. All very solid OO
development only.

-pj


--------------000906040602070708060706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit







Alexandr Ciornii wrote:
cite="mid:2f1541220903231306g2a7e8e1fu90c2ef682c9fa54f@mail. gmail.com"
type="cite">

Hi.



It possible to encrypt perl sources with same safety as with PHP -

with possibility of source decryption. But Perl developers are in

general more advanced than PHP developers so they know how to decrypt

it, in contrast to PHP developers that do not know that encrypted PHP

sources can easily be decrypted. There are also some bytecode

compilers for Perl (alpha stage).



2009/3/23 Octavian Râsnita :



  

PHP, C#, Java are much more prefered, because the programs created with them

can hide the source code much better, while this is not possible with Perl.

This is a big reason why the software companies that create custom programs

for their clients prefer to use those languages and not perl. Not because

perl is bad.

    

Re: decline and fall of modperl?

Hi.

Filter::Crypto on CPAN. It even works with PAR. And it is free.

2009/3/23 Octavian R=E2snita :

> Can I encrypt some .pm modules in such a way that they couldn't be decryp=
ted
> easier than the PHP files encrypted by Zend Encoder?
> If yes, please tell us how, because it would be a really important
> information for the perl developers.

--=20
Alexandr Ciornii, http://chorny.net

Re: decline and fall of modperl?

Perrin Harkins wrote:
> On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita wrote:
....and in most parts of the
>> world it is hard to find competent perl programmers.
>
> ...The job
> listings for Perl are strong. They're huge compared to those for
> Ruby. Of course Java is massively more popular than either of them,
> but that doesn't make the perl market small.

I wouldn't use the word 'most', but here in Southeast Asia it's a real
challenge to find a Perl developer with significant experience in Perl/
modperl. Those who do use it as a minor scripting tool in their unix
administration.

There are still jobs requiring Perl of course, but it's usually in the
context of having Perl as a secondary proficiency, with Java/ .NET as
the primary. We have a real problem getting the average freshie to
appreciate the beauty of dynamic languages.

Sorry guys.

Re: decline and fall of modperl?

--0-201917949-1237861570=:82811
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Very interesting topic, byline and responses.
=A0
For the last 5 years I have been Perl recruiter (24 years overall as a tech=
nical=A0headhunter)=A0based out of Southern Ca.=20
=A0
Many on this list have talked/worked with me, most however would not recogn=
ize this screen name.
=A0
I would be more than happy to share my insights as it relates to the "job" =
/ "candidate" market conditions.
=A0
If there are enough affirmative replies I will in the near future=A0 post a=
more detailed dissertation.=20
=A0
If not, I will continue to lurk in the shadows.
=A0
Long live PERL

--- On Mon, 3/23/09, Louis-David Mitterrand rg> wrote:


From: Louis-David Mitterrand
Subject: decline and fall of modperl?
To: modperl@perl.apache.org
Date: Monday, March 23, 2009, 6:07 AM


-----Inline Attachment Follows-----


Hi and sorry for the provocative title of my post :)

One of our customers is doing a detailed review of a mason/modperl ERP
app we've built for them since 2001. Prodded by some buzzword-compliant
consultants they are expressing concerns that the app's underlying
technologies - perl, modperl and mason - are becoming obsolete. They
feel that a web application framework must have 'rails' or some other
buzzword in its name.

But their main argument is that perl is declining as a web developement
language. Also they rightly feel that competent perl developers are
becoming harder to find.

What arguements could I use to address these concerns and convince them
that their initial investement in perl is still safe and won't be
obsolete in 10 years?

The client's local developers (who maintain the app we've built) feel
that mason gives too much freedom to write messy code and badly
structure a web app.=20

Indeed mason has very little constraints, maybe just slightly more than
straight modperl. So it requires experienced, self-disciplined devs,
which are few and far between.

So my second question is, what perl web development framework should we
recommend to our client? Catalyst looks like a winner, but maybe there
are others?

Thanks for your insights,
=0A
--0-201917949-1237861570=:82811
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Re: decline and fall of modperl?

--000e0cd32e3e4a34130465d4a59e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

From a fellow lurker to another, I would be interested in reading your
perspective.

- Marilyn

On Mon, Mar 23, 2009 at 7:26 PM, Mike Bourdon wrote:

> Very interesting topic, byline and responses.
>
> For the last 5 years I have been Perl recruiter (24 years overall as a
> technical headhunter) based out of Southern Ca.
>
> Many on this list have talked/worked with me, most however would not
> recognize this screen name.
>
> I would be more than happy to share my insights as it relates to the "job"
> / "candidate" market conditions.
>
> If there are enough affirmative replies I will in the near future post a
> more detailed dissertation.
>
> If not, I will continue to lurk in the shadows.
>
> Long live PERL
>
> --- On *Mon, 3/23/09, Louis-David Mitterrand <
> vindex+lists-modperl@apartia.org >*wrote:
>
>
> From: Louis-David Mitterrand
> >
> Subject: decline and fall of modperl?
> To: modperl@perl.apache.org
> Date: Monday, March 23, 2009, 6:07 AM
>
>
> -----Inline Attachment Follows-----
>
> Hi and sorry for the provocative title of my post :)
>
> One of our customers is doing a detailed review of a mason/modperl ERP
> app we've built for them since 2001. Prodded by some buzzword-compliant
> consultants they are expressing concerns that the app's underlying
> technologies - perl, modperl and mason - are becoming obsolete. They
> feel that a web application framework must have 'rails' or some other
> buzzword in its name.
>
> But their main argument is that perl is declining as a web developement
> language. Also they rightly feel that competent perl developers are
> becoming harder to find.
>
> What arguements could I use to address these concerns and convince them
> that their initial investement in perl is still safe and won't be
> obsolete in 10 years?
>
> The client's local developers (who maintain the app we've built) feel
> that mason gives too much freedom to write messy code and badly
> structure a web app.
>
> Indeed mason has very little constraints, maybe just slightly more than
> straight modperl. So it requires experienced, self-disciplined devs,
> which are few and far between.
>
> So my second question is, what perl web development framework should we
> recommend to our client? Catalyst looks like a winner, but maybe there
> are others?
>
> Thanks for your insights,
>
>
>

--000e0cd32e3e4a34130465d4a59e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

From a fellow lurker to another, I would be interested in reading your pers=
pective.

- Marilyn

Re: decline and fall of modperl?

On Mon, 23 Mar 2009 22:26:10 -0400, Mike Bourdon
wrote:

> I would be more than happy to share my insights as it relates to the
> "job" / "candidate" market conditions.
>  
> If there are enough affirmative replies I will in the near future  post
> a more detailed dissertation.
>  
> If not, I will continue to lurk in the shadows.
>  
> Long live PERL
>

Affirmative.

--
ispy++

Re: decline and fall of modperl?

Alexandr Ciornii wrote:
>
>> PHP, C#, Java are much more prefered, because the programs created with them
>> can hide the source code much better, while this is not possible with Perl.
>> This is a big reason why the software companies that create custom programs
>> for their clients prefer to use those languages and not perl. Not because
>> perl is bad.
>
I would like to add that it seems ridiculously simple to decompile Java
classes.
I find this a bad argument. My company - admittedly small - sells
services and software to customers. 90% of our software is written in
Perl, and we supply it in source format.
None of our customers in their right mind would even think of stealing
the code, although it is extremely well-commented throughout. If they
had the time to do that, then they would not have asked us to supply the
service in the first place.

Ultimately, and back to the OP's orginal question, these are the two or
three main arguments in this debate, mainly already provided by other
contributors :

1) if you have a customer and you provide a good service to this
customer, and you have provided it for years, and you provide it at a
fair price, then why should they listen to a fresh-landed consultant
instead of listening to you ?
If they listen to the consultant and ignore your advice, then the
problem is not in the programming language you use.

2) it is easy for anyone to use words like "obsolete", but what to these
words really mean ? is something that hasn't much changed in 10 years
automatically "obsolete" ? if yes, then the WWW is obsolete, and the
decision-maker at your customer company is also obsolete.
Something becomes really obsolete the day when something else is
available, and it performs the same function better and at a lower cost.
Is that the case here ?

3) it is true that perl has somehow become less "in vogue", consistently
over the last few years. The (apparently aging) perl community is
largely aware of the fact and deplores it. The critics to perl always
seem to rehash the same things (the funny variable prefixes, the
possibility of writing bad code, the "write-only" aspect - you can never
re-read the code, and so on). Mostly these critics are people who do not
really know the language. But it is not because there are comparatively
fewer perl programmers available that perl is an inferior language.
There are thousands of so-called MS-Windows or PHP experts available,
yet you have to hire ten and then fire nine, to keep the one who is
really competent. That's always more expensive than getting the right
person from the start.
Anyway, I am not so sure that there are really less perl programmers,
and less perl-based projects or sites. It may just be that whatever
those people do, they do it quietly, competently and without fuss; and
that the projects or sites which are based on perl are less in the news
because they don't crash and don't overrun their budgets.
It seems a bit like turning things on their head. I mean if there are a
lot of job adverts for PHP or Java developers, it must mean that PHP or
Java projects need a lot of manpower, no ? So conversely..

RE: decline and fall of modperl?

This is a multi-part message in MIME format.

----=_Part_210DEA46DD8F4F4AB871B76B944458A0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

if nobody did already, please have a look at the Perl Miths presentation by Tim Bunce:

http://timbunce.files.wordpress.com/2008/03/perl-myths-20080 2-with-notes.pdf

Now my personal view:

I'm committed to perl since 1996, and, although I work since that date in a quite big software company (>250 employees, and Microsoft certified partner), I remember to have had very seldom problems convincing customers about technology issues like which language to use.

Regarding your experience, I would not confuse the future of Mason with the future of perl in the web programming sector at large.
There are similar experiences in other technologies: in the J2EE domain, Jetspeed is almost dead, this doesn't mean J2EE is dead (but it really means you will have problems convincing a system architect to adopt Jetspeed for the next web portal).

I'm involved in web programming since 1999 and at that time there were really little choices. We started building our own LAMP (Linux+Apache+ModPerl !) framework that now is the backbone of our solutions anytime the customer gives us the freedom to choose. Sometimes the customer has other technologies in mind, but we always convince him with an unbeatable time-to-market using our own tools.
In spite of being a 'simple scripting language' we do not see major problems in mantaining and evolving our framework of 500+ perl modules.

Moreover I mind you that there are sectors where perl is still one of the best choice to pick (Natural Language Processing, web crawling, data mungling at large...).

The long history of Perl means also that it is much more common to find it at your customers sites than what you could immagine. Some times I talk about Perl admittedly with a little fear, only to find that most of the clients know it already and have already used it at least in the past.

So personally I still love Perl and I'm still happy to have learnt it some 13 years ago, and I'm happy that now it is seen as an 'obsolete' technology: for me it only means that is rock solid and that I learnt once in the past, exploiting my knowledge for several years without the need to switch.

I think this goes for the most of perl programmers out there. The problem is that Perl is not able to attract new programmers as other tecnologies (Java/.NET) are.

One issue being the lack of a common and powerfull development framework as other technology have (MS Visualstudio/NetBeans). And, of course, the not-so-fast transition between Perl 5 and Perl 6 could also be an issue.

Finally, regarding the issue of not being forced to deploy the source code: sometimes we deployed perl bytecode for the ByteLoader, and I found the level of security is almost the same than with java bytecode (if you know how to deparse one, you are able to find how to do with the other...).

Best,
Marco.


----- Original Message -----
From: Louis-David Mitterrand [mailto:vindex+lists-modperl@apartia.org]
To: modperl@perl.apache.org
Sent: Mon, 23 Mar 2009 14:07:31 +0100
Subject: decline and fall of modperl=3F

Hi and sorry for the provocative title of my post :)

One of our customers is doing a detailed review of a mason/modperl ERP
app we've built for them since 2001. Prodded by some buzzword-compliant
consultants they are expressing concerns that the app's underlying
technologies - perl, modperl and mason - are becoming obsolete. They
feel that a web application framework must have 'rails' or some other
buzzword in its name.

But their main argument is that perl is declining as a web developement
language. Also they rightly feel that competent perl developers are
becoming harder to find.

What arguements could I use to address these concerns and convince them
that their initial investement in perl is still safe and won't be
obsolete in 10 years=3F

The client's local developers (who maintain the app we've built) feel
that mason gives too much freedom to write messy code and badly
structure a web app.

Indeed mason has very little constraints, maybe just slightly more than
straight modperl. So it requires experienced, self-disciplined devs,
which are few and far between.

So my second question is, what perl web development framework should we
recommend to our client=3F Catalyst looks like a winner, but maybe there
are others=3F

Thanks for your insights,


----=_Part_210DEA46DD8F4F4AB871B76B944458A0--

Re: decline and fall of modperl?

Marilyn Burgess schrieb:
> >From a fellow lurker to another, I would be interested in reading
> your perspective.
>
> - Marilyn
>
me too,
Axel

Re: decline and fall of modperl?

André Warnier wrote:
> I would like to add that it seems ridiculously simple to decompile Java
> classes.
Agreed. With the popularity of bytecode languages such as Java and .Net,
suddenly nobody talks about the ease of obtaining source code in the
flesh. As Andre mentioned, it's trivial to decompile .Net DLLs.

I tried to recover an old perl app packaged by ActivePerl some time
back. It was impossible to do this, and the good guys at AP verified my
pain. If anything I'd say that I feel confident my (AP-packaged)
products will not fare any worse than any commercial Java/ .Net
executables in the wild.

Re: decline and fall of modperl?

> Perrin Harkins wrote:
>> On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita
>> wrote:
> ...and in most parts of the
>>> world it is hard to find competent perl programmers.
>>
>> ...The job
>> listings for Perl are strong. They're huge compared to those for
>> Ruby. Of course Java is massively more popular than either of them,
>> but that doesn't make the perl market small.
>
> I wouldn't use the word 'most', but here in Southeast Asia it's a real
> challenge to find a Perl developer with significant experience in Perl/
> modperl. Those who do use it as a minor scripting tool in their unix
> administration.
>
Having run a Perl and Java based technology company in Singapore myself
for a chunk of time in the early 2000s, I agree that there is some truth
to that. We did run into that as an issue and did end up importing Perl
and mod_perl talent overseas including some people who post here
relatively regularly who were able to enjoy a stay in SE Asia.

However, some markets are going to be a bit different. I think what you
are saying reflects also what a search of a Singaporean jobs database has
in it. Whereas in USA and Europe PHP = Perl in # of jobs, even in
Singapore, the number of Perl jobs is less than half of PHP and both small
than Java. From jobstreet.com.sg, Perl:18, PHP:51, Java: 210

With that said, that forms a relatively small n looking at one country --
although I imagine there should be little difference in Malysia etc. At
the risk of sounding American-centric, the number of jobs in America and
Europe is nonetheless a good chunk of the technology development in the
world so I believe the statistics are still compelling on those job sites
about relative use of the technology

-- Gunther

Fw: Re: decline and fall of modperl?

--0-2019039742-1237926402=:29610
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable









I have received a fair amount of affirmatives. So here goes....=20
 =20
Let me first begin by stating that my observations are anecdotal. They are =
however based on direct conversations with hiring managers / senior develop=
ers at my clients/prospects.  I have also interviewed well over 400 pe=
rl/oo perl/mod_perl developers in the last 4 years. I have an extremely det=
ailed code vetting process that allows an accurate skill level rating.=20
 =20
I am sure there will be plenty of situational disparity between what I writ=
e and what you may have personally experienced.=20
 =20
The â€=9Cjobâ€=9D market…
 =20
Most large scale shops (more than a few perl/oo perl/mod_perl developers) h=
ave code bases that where developed in the late 90â€=99s (hence a resis=
tance to moved towards more robust but yet unproven versions). These compan=
ies have survived the dot com blowup and grown in their respective market p=
laces, usually internet/web commerce centric. Most new startups/companies (=
there are exceptions) are not perl/oo perl/mod_perl shops.=20
 =20
The jobs are literally spread across the country. In each geographical area=
, shops know most of the â€=9Clocalâ€=9D perl/oo perl/mod_perl deve=
lopers/coders. They have already worked with these coders or interviewed th=
em at some point in time.  In some cases they have current employees t=
hat have worked with and know of them. For whatever reasons they are deemed=
not technically or chemistry qualified.  When they do talk to Java/J2=
ee / MS .net developers (who accept perl only as a procedural language used=
for the most part by Linux sysads) it is very rare there will be any ship =
jumping. Itâ€=99s like the McCoys and the Hatfields. In other words the=
talent pool doesnâ€=99t expand.=20
 =20
The Southern Ca market has the highest geographical concentration of large =
scale perl/oo perl/mod_perl shops (although relatively quite at the moment =
in terms of hiring). It is arguably the center of the universe as it relate=
s to media/content/advertising and the merging of these with web portals. S=
outhern Ca is also a relocation destination. This lends itself to more =E2=
€œlocalâ€=9D talent and therefore more perl/oo perl/mod_perl start =
ups. The hidden message here is â€=9Cthe more available senior develope=
rs, the more likely available jobsâ€=9D, an expanding talent pool will =
lead to an expanding job market.=20
 =20
In my humble opinion the perl community needs to embrace the concept of sel=
f propagation. For the most part perl/oo perl/mod_perl developers are self =
taught. Junior or mid level talent (a majority of the talent pool) is passe=
d over as not enough experience. Perhaps this is because they do not push t=
hemselves or the roles they come from are User Interface or system ops, peo=
ple that did not make it in those roles.  This where as an investment =
of time and effort can go a long way into building the pool of perl/oo perl=
/mod_perl developers. Too often everyone is looking for the instant gratifi=
cation of a senior level skill set.=20
 =20
Believe it or not, there is a perception that senior perl/oo perl/mod_perl =
developers do not play well with others. An active mentoring role played by=
senior developers and gurus needs to be taken. Reach out and take a junior=
person under your wing and actively work to raise their level of coding sk=
ill set. Perl/oo perl/mod_perlâ€=99s community and your future may=
depend on it.

--- On Mon, 3/23/09, Mike Bourdon wrote:


From: Mike Bourdon
Subject: Re: decline and fall of modperl?
To: "Louis-David Mitterrand"
Cc: modperl@perl.apache.org
Date: Monday, March 23, 2009, 7:26 PM







Very interesting topic, byline and responses.
 
For the last 5 years I have been Perl recruiter (24 years overall as a tech=
nical headhunter) based out of Southern Ca.=20
 
Many on this list have talked/worked with me, most however would not recogn=
ize this screen name.
 
I would be more than happy to share my insights as it relates to the "job" =
/ "candidate" market conditions.
 
If there are enough affirmative replies I will in the near future  pos=
t a more detailed dissertation.=20
 
If not, I will continue to lurk in the shadows.
 
Long live PERL

--- On Mon, 3/23/09, Louis-David Mitterrand rg> wrote:


From: Louis-David Mitterrand
Subject: decline and fall of modperl?
To: modperl@perl.apache.org
Date: Monday, March 23, 2009, 6:07 AM


-----Inline Attachment Follows-----


Hi and sorry for the provocative title of my post :)

One of our customers is doing a detailed review of a mason/modperl ERP
app we've built for them since 2001. Prodded by some buzzword-compliant
consultants they are expressing concerns that the app's underlying
technologies - perl, modperl and mason - are becoming obsolete. They
feel that a web application framework must have 'rails' or some other
buzzword in its name.

But their main argument is that perl is declining as a web developement
language. Also they rightly feel that competent perl developers are
becoming harder to find.

What arguements could I use to address these concerns and convince them
that their initial investement in perl is still safe and won't be
obsolete in 10 years?

The client's local developers (who maintain the app we've built) feel
that mason gives too much freedom to write messy code and badly
structure a web app.=20

Indeed mason has very little constraints, maybe just slightly more than
straight modperl. So it requires experienced, self-disciplined devs,
which are few and far between.

So my second question is, what perl web development framework should we
recommend to our client? Catalyst looks like a winner, but maybe there
are others?

Thanks for your insights,


=0A
--0-2019039742-1237926402=:29610
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Re: Fw: Re: decline and fall of modperl?

Mike Bourdon wrote:
>
>
> In my humble opinion the perl community needs to embrace the concept
> of self propagation. For the most part perl/oo perl/mod_perl
> developers are self taught. Junior or mid level talent (a majority
> of the talent pool) is passed over as not enough experience. Perhaps
> this is because they do not push themselves or the roles they come
> from are User Interface or system ops, people that did not make it
> in those roles. This where as an investment of time and effort can
> go a long way into building the pool of perl/oo perl/mod_perl
> developers. Too often everyone is looking for the instant
> gratification of a senior level skill set.
>
> Believe it or not, there is a perception that senior perl/oo
> perl/mod_perl developers do not play well with others. An active
> mentoring role played by senior developers and gurus needs to be
> taken. Reach out and take a junior person under your wing and
> actively work to raise their level of coding skill set. Perl/oo
> perl/mod_perl’s community and your future may depend on it.

I completely agree with what you're saying here. At my previous
employer (i changed jobs in august) we found it pretty much impossible
to find entry/mid level perl people, so what we did was hire entry level
people straight out of school that had maybe a little bit of perl, but
displayed the chops to be able to learn what we needed them to learn.
This worked out great for us, and i know it's been the way that at least
a couple of other small perl shops in Toronto have been building their
teams. If you can find a good programmer, it easy to turn them into a
good perl programmer if they are willing.

Right now, in Toronto if you're looking to hire a senior level perl
programmer you're looking at 75K plus CAD. There are a couple of well
funded shops in the city that will throw 6 figures at the right candidate.

The mentoring thing is huge though. Perl generally isn't taught in
schools, and if you're building a team from the ground up, you're going
to have to teach. Which is in a lot of ways actually a good thing,
because you can hopefully teach people Modern Perl, instead of the
formmail.pl style perl ;)

This is part of the reason why i'd love to see more tutorial style
documentation on perl.apache.org.

Adam

Re: Fw: Re: decline and fall of modperl?

> In my humble opinion the perl community needs to embrace the concept
> of self propagation. For the most part perl/oo perl/mod_perl
> developers are self taught. Junior or mid level talent (a majority
> of the talent pool) is passed over as not enough experience.
It is interesting for me to hear that developed countries are also
having difficulties finding Perl-savvy developers out of the varsities.
I do agree that not being able to find 'Perl-ready' graduates should not
be a deterrant - I myself being a brainwashed Java advocate for a while
before stumbling onto Perl.

In my local context, deciding on Perl/ PHP/ Ruby requires a great deal
of support on the business side:

1. The average turnover rate is about 3 years. That means every 3 years
you have to retrain a new guy to take over relatively established code.
Since we have to accept the fact that it's extremely difficult to hire
an experienced Perl dev, the quality and experience of the dev team
halts at about 5-6 years.
- New strategies will be have to be formed to distinguish the core
engine from the customisable. The company must recognise the business
viability in retaining the core team, while accepting that the mediocre
will move on in time. The core team itself has to develop good mentoring
and training skills to induct the new intake.

2. Selling to clients who only understand .NET and Java ('modern'
languages) will be a challenge. Governments and large enterprises
generally (and mistakeably) associate other languages to be an
investment risk.
- Nobody asks about the innards of an appliance or a product. As long as
it runs, runs well and affordably, it's good enough.

Sounds reasonable enough, but it's a lot work to get there...

Re: decline and fall of modperl?

From: "Joel Bernstein"
On 23 Mar 2009, at 21:18, Octavian Râsnita wrote:
> Can I encrypt some .pm modules in such a way that they couldn't be
> decrypted easier than the PHP files encrypted by Zend Encoder?
> If yes, please tell us how, because it would be a really important
> information for the perl developers.

> No idea. Can you make this a question against a measurable target?

A pretty simple or medium simple application which is encrypted should not
be decrypted easy enough to worth the effort of doing this.
The encrypting solution should be very simple to implement.

> I'm not sure what makes you think that the Zend Encoder files are not
recoverable, anecdotal evidence online suggests that they are.

I haven't seen any prove that they can be decrypted easy enough to worth the
effort.
Modifying the perl or PHP interpreter to save the generated source code
instead of compiling and executing it, or creating a program that monitors
the memory and unobfuscate the found source code it is a too big effort and
it would be much easier to re-create the program instead of decrypting it.

> In any case, I've barely heard of a Perl developer who wants this
> feature. Nobody needs encrypted Perl source. It runs in an interpreter.
> No point, no value, and nobody wants this feature. Nobody's worked on a
> good implementation because it'd be a waste of time and resources.
>
> /joel=

The actual perl programmers are not important, because they already have
their reasons for using perl.
Are you saying that nobody uses Zend Encoder because PHP also runs using an
interpreter?
I really doubt it.

There are very many software companies that create PHP source code but offer
just the Zend Encrypted programs and not the source code.
It would be very good if those software companies would know that they could
do the same programs in perl, and offer the same protection.

I tested Filter::Crypto and it is great!
It is a free code so we can't expect to be as easy to use as Zend Encoder,
but if we compare it with Zend Encoder, its main problem is that it is not
so much promoted as Zend Encoder.

I've tried to install it using cpan under Linux, but it gave an error, so I
needed to force install it.
I've also tried to install it under Windows, but it required Open SSL, so I
needed to download and compile that software first.
There is a PPM package for Windows and it installs fine, but it doesn't say
that it requires Open SSL, and after I installed it, I found that it doesn't
work without installing Open SSL.
Strangely, but after I installed Open SSL under Windows, I was able to
install it using cpan, and it didn't give any error (unlike under Linux).

I've tested it with a few programs, including the main module of a Catalyst
application, and it worked very well.

Octavian

Re: Re: decline and fall of modperl?

This is a multi-part message in MIME format.

------=_NextPart_000_00A9_01C9AD76.361790B0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

From: Mike Bourdon=20
> The hidden message here is â€=9Cthe more available senior =
developers, the more likely available=20
> jobsâ€=9D, an expanding talent pool will lead to an expanding job =
market.=20

I fully agree. What happends in the regions where there are extremely =
few perl programmers, no matter if they are good or bad... we can =
imagine.
What can we do in order to promote perl in those countries/regions?

There are almost no translated books for learning perl in my country, =
and the editors are not very interested in printing perl books because =
they won't sell well enough, and those few which would be interested =
would probably pirate them.
Without books and without funds for promoting perl for beeing taught in =
schools, perl won't have any chance in face of DotNet or Java.

> In my humble opinion the perl community needs to embrace the concept =
of self propagation. For=20
> the most part perl/oo perl/mod_perl developers are self taught. Junior =
or mid level talent (a=20
> majority of the talent pool) is passed over as not enough experience. =
Perhaps this is because=20
> they do not push themselves or the roles they come from are User =
Interface or system ops,=20
> people that did not make it in those roles. This where as an =
investment of time and effort can > go a long way into building the pool =
of perl/oo perl/mod_perl developers. Too often everyone is > looking for =
the instant gratification of a senior level skill set.=20

True, but how to do this practicly?
I tried to convince some programmers that Perl is better than PHP, but =
without any success.

Can perl programs run on share hosting web sites? There are some such =
hosting companies that don't even offer perl support, and those who =
offer it, offer just the standard Perl distribution, which don't offer a =
web framework, or templating systems, or ORMS, or form processors, and =
in these conditions I can't tell that perl is so great.

Can they hide the source code? (Because who knows who can get it from =
those free hosting web sites)
I found that they can hide it, but only after installing Open SSL and a =
perl module, which they can't do, because those sites don't offer root =
access and neither shell access.

In order to show them how good is perl, I told them that they would need =
to have a dedicated server, or a VPS, but the cheapest VPS costs much =
more than a shared hosting solution, so in this case perl has another =
disadvantage.

They've also told me that they know that perl is harder to learn than =
PHP.
What can I tell them? That it is not true?
Of course that I could have told them that for real good big projects, =
perl is easier to use than PHP, but most of the PHP users don't care =
about that kind of projects. They care about simple projects created =
from scratch, that don't even use a web framework or an ORM or a form =
processor.

But finally those poor PHP programmers find more jobs than a perl =
programmer.

Octavian

------=_NextPart_000_00A9_01C9AD76.361790B0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

ï»=BF

Re: decline and fall of modperl?

Perrin Harkins wrote:
> TicketMaster is Perl.

Ticketmaster switched their UK operation from MS technologies to mod_perl a
couple of years back too. (Brought it inline with the US side.)

There's a couple of biggies that haven't been mentioned...

BBC
YouPorn (although I don't think they use mod_perl)

You could also ask the question of why Twitter has a shelf of perl books:

http://twitter.com/jobs

;-)

Carl

Re: decline and fall of modperl?

Carl Johnstone wrote:
> Perrin Harkins wrote:
>> TicketMaster is Perl.
>
> Ticketmaster switched their UK operation from MS technologies to mod_perl a
> couple of years back too. (Brought it inline with the US side.)
>
> There's a couple of biggies that haven't been mentioned...
>
> BBC
> YouPorn (although I don't think they use mod_perl)
>
> You could also ask the question of why Twitter has a shelf of perl books:
>
> http://twitter.com/jobs
>

facebook mirrors CPAN at http://mirror.facebook.com/ so it seems pretty
likely that they are using it there too at least for sysadmin type stuff.

Adam

Re: decline and fall of modperl?

This is a multi-part message in MIME format.
--------------080404040703080303060700
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Octavian Râşniţă wrote:
> From: Mike Bourdon
> > The hidden message here is “the more available senior developers,
> the more likely available
> > jobs”, an expanding talent pool will lead to an expanding job market.
>
> I fully agree. What happends in the regions where there are extremely
> few perl programmers, no matter if they are good or bad... we can imagine.
> What can we do in order to promote perl in those countries/regions?
A programmers guild? Providing training, guidance, and advocacy in the
market?
> There are almost no translated books for learning perl in my country,
> and the editors are not very interested in printing perl books because
> they won't sell well enough, and those few which would be interested
> would probably pirate them.
> Without books and without funds for promoting perl for beeing taught
> in schools, perl won't have any chance in face of DotNet or Java.
I think you've got it right there. We've got to get perl taught in
schools. That means perl experts need to be in teaching. And I have a
suspicion that perl doesn't appeal to the pure computer scientist very
well - these are the people who invented hard typed languages, after all.
> > In my humble opinion the perl community needs to embrace the concept
> of self propagation. For
> > the most part perl/oo perl/mod_perl developers are self taught.
> Junior or mid level talent (a
> > majority of the talent pool) is passed over as not enough
> experience. Perhaps this is because
> > they do not push themselves or the roles they come from are User
> Interface or system ops,
> > people that did not make it in those roles. This where as an
> investment of time and effort can > go a long way into building the
> pool of perl/oo perl/mod_perl developers. Too often everyone is >
> looking for the instant gratification of a senior level skill set.
>
> True, but how to do this practicly?
> I tried to convince some programmers that Perl is better than PHP, but
> without any success.
How could they know, if they have never used it? I was far less
convinced that PHP was a blight on the face of scripting science until I
got a job working in it, after all.

Pay them to do it in perl, and after they get through the learning curve
they'll probably be much happier with it.
> Can perl programs run on share hosting web sites? There are some such
> hosting companies that don't even offer perl support, and those who
> offer it, offer just the standard Perl distribution, which don't offer
> a web framework, or templating systems, or ORMS, or form processors,
> and in these conditions I can't tell that perl is so great.
Isn't that to the denigration of the hosting company? Not supporting
the framework is no way to support your user base. As long as the
dollar is more important than the feature, there's not much we can do
about this. These are not things that should be built into the core
distribution of a language, its the main reason PHP is so awful.
> Can they hide the source code? (Because who knows who can get it from
> those free hosting web sites)
Who cares? Hiding source code is valueless.
> I found that they can hide it, but only after installing Open SSL and
> a perl module, which they can't do, because those sites don't offer
> root access and neither shell access.
You get what you pay for I guess.
> In order to show them how good is perl, I told them that they would
> need to have a dedicated server, or a VPS, but the cheapest VPS costs
> much more than a shared hosting solution, so in this case perl has
> another disadvantage.
If they care that much about a few $ on a monthly fee for their web
site, they're not going to pay enough to get a skilled programmer in ANY
language, to do the programming.
> They've also told me that they know that perl is harder to learn than PHP.
> What can I tell them? That it is not true?
Yes, but you may or may not be right. We all agree that coming into
perl is confusing - too much old data about how to do things is out
there in the world. That makes it harder to learn - not because the
language is harder to learn - but because its not clear what the proper
way to learn it is.
> Of course that I could have told them that for real good big projects,
> perl is easier to use than PHP, but most of the PHP users don't care
> about that kind of projects. They care about simple projects created
> from scratch, that don't even use a web framework or an ORM or a form
> processor.
Sounds like the people who buy expensive fixed-lense cameras, then the
moment they get interested in photography discover that they could have
bought an SLR, more capable and flexible, for the same price. But they
swore they didn't need the capability to do that when they bought the
original cameras, so now they're screwed.

The value is that you start with something that will scale, because
believe it or not, its going to grow - either the one you're working on
or the next one you're going to work on, leveraging what you learned in
this job.

But not everybody sees programming as all that, which is probably just
another argument for a guild...
> But finally those poor PHP programmers find more jobs than a perl
> programmer.
Poor programmers will always be more employed than skilled programmers -
not only are they in greater abundance, they simply cannot demand the
value that skilled programmers can.

David


--------------080404040703080303060700
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit







Octavian Râşniţă wrote:

type="cite">

From: Mike Bourdon

> The hidden message here is “the more available senior developers,
the more likely available

> jobs”, an expanding talent pool will lead to an expanding job
market.

 

I fully agree. What happends in the
regions where there are extremely few perl programmers, no matter if
they are good or bad... we can imagine.

What can we do in order to promote perl in those countries/regions?

type="cite">

There are almost no translated books
for learning perl in my country, and the editors are not very
interested in printing perl books because they won't sell well enough,
and those few which would be interested would probably pirate them.

Without books and without funds for promoting perl for beeing taught in
schools, perl won't have any chance in face of DotNet or Java.

type="cite">

> In my humble opinion the perl
community needs to embrace the concept of self propagation. For

> the most part perl/oo perl/mod_perl developers are self taught.
Junior or mid level talent (a

> majority of the talent pool) is passed over as not enough
experience. Perhaps this is because

> they do not push themselves or the roles they come from are User
Interface or system ops,

> people that did not make it in those roles.  This where as an
investment of time and effort can > go a long way into building the
pool of perl/oo perl/mod_perl developers. Too often everyone is >
looking for the instant gratification of a senior level skill set.

 

True, but how to do this practicly?

I tried to convince some programmers that Perl is better than PHP, but
without any success.

type="cite">

Can perl programs run on share
hosting web sites? There are some such hosting companies that don't
even offer perl support, and those who offer it, offer just the
standard Perl distribution, which don't offer a web framework, or
templating systems, or ORMS, or form processors, and in these
conditions I can't tell that perl is so great.

type="cite">

Can they hide the source code?
(Because who knows who can get it from those free hosting web sites)

type="cite">

I found that they can hide it, but
only after installing Open SSL and a perl module, which they can't do,
because those sites don't offer root access and neither shell access.

type="cite">

In order to show them how good is
perl, I told them that they would need to have a dedicated server, or a
VPS, but the cheapest VPS costs much more than a shared hosting
solution, so in this case perl has another disadvantage.

type="cite">

They've also told me that they know
that perl is harder to learn than PHP.

What can I tell them? That it is not true?

type="cite">

Of course that I could have told
them that for real good big projects, perl is easier to use than PHP,
but most of the PHP users don't care about that kind of projects. They
care about simple projects created from scratch, that don't even use a
web framework or an ORM or a form processor.

type="cite">

But finally those poor PHP
programmers find more jobs than a perl programmer.

Re: decline and fall of modperl?

This is a multi-part message in MIME format.

------=_NextPart_000_0186_01C9ADA6.387ECBE0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

From: David Ihnen=20
Octavian Râşniţă wrote:=20
From: Mike Bourdon=20
> The hidden message here is â€=9Cthe more available senior =
developers, the more likely available=20
> jobsâ€=9D, an expanding talent pool will lead to an expanding =
job market.=20

I fully agree. What happends in the regions where there are =
extremely few perl programmers, no matter if they are good or bad... we =
can imagine.
What can we do in order to promote perl in those countries/regions?
A programmers guild? Providing training, guidance, and advocacy in =
the market?

There are almost no translated books for learning perl in my =
country, and the editors are not very interested in printing perl books =
because they won't sell well enough, and those few which would be =
interested would probably pirate them.
Without books and without funds for promoting perl for beeing taught =
in schools, perl won't have any chance in face of DotNet or Java.
> I think you've got it right there. We've got to get perl taught in =
schools. That means perl experts need to be in teaching. And I have a=20
> suspicion that perl doesn't appeal to the pure computer scientist =
very well - these are the people who invented hard typed languages, =
after all.

True. I know some guys that love math and all of them love more the =
strongly typed languages.
Maybe I don't like the strongly typed languages because I attended a =
university and a high school in business and economics.

> I tried to convince some programmers that Perl is better than PHP, =
but without any success.
> How could they know, if they have never used it? I was far less =
convinced that PHP was a blight on the face of scripting science until I =
got a=20
> job working in it, after all.

They know it because everybody tell them so. Most web sites are done =
in PHP, most job offer for web programmers ask for PHP experience...

> Pay them to do it in perl, and after they get through the learning =
curve they'll probably be much happier with it.

I can't tell that in my country there are no software companies =
specialized in perl programming because I don't know all the software =
companies, but if there are some, they could be counted on fingers, and =
they aren't probably very big.
So who should pay those PHP programmers in order to motivate them?

Can perl programs run on share hosting web sites? There are some =
such hosting companies that don't even offer perl support, and those who =
offer it, offer just the standard Perl distribution, which don't offer a =
web framework, or templating systems, or ORMS, or form processors, and =
in these conditions I can't tell that perl is so great.
Isn't that to the denigration of the hosting company? Not supporting =
the framework is no way to support your user base. As long as the =
dollar is more important than the feature, there's not much we can do =
about this. These are not things that should be built into the core =
distribution of a language, its the main reason PHP is so awful.

I agree that those things shouldn't be built in the core distribution, =
but there could be more distributions, like the one offered by =
ActiveState, or Strawberry Perl or others, just as the Zend PHP =
distribution contains the Zend Framework.

It could be helpful to have a perl distribution that includes the =
latest versions of Template-Toolkit, HTML::Template, Mason, Catalyst, =
CGI::Application, DBIx::Class, Moose, HTML::FormFu and other helpful =
cpan modules.
A hosting company may want to install that distribution, and it would =
really offer a much better support than the one offered by PHP.
Yes, those modules won't be updated frequently, but it would be much =
better than simply a CGI.pm support.

> Can they hide the source code? (Because who knows who can get it =
from those free hosting web sites)
> Who cares? Hiding source code is valueless.

Maybe in your country. In my country 10 euro means too much and =
actually even 1 euro means too much if the same thing can be got for =
free, legally or not.

> I found that they can hide it, but only after installing Open SSL =
and a perl module, which they can't do, because those sites don't offer =
> root access and neither shell access.
> You get what you pay for I guess.


Well, they can get a free support offered for Zend Optimizer (or how =
it is called the Zend Decoder).

> In order to show them how good is perl, I told them that they =
would need to have a dedicated server, or a VPS, but the cheapest VPS > =
costs much more than a shared hosting solution, so in this case perl has =
another disadvantage.
> If they care that much about a few $ on a monthly fee for their web =
site, they're not going to pay enough to get a skilled programmer in ANY =
> > language, to do the programming.


Of course they care. If the same thing can be done cheaper using =
PHP, they will surely choose PHP.
(The quality doesn't matter, because here the things are so fast =
changing, and the easiness of maintenance doesn't matter for most, =
because who knows what will happen after a few years.


> They've also told me that they know that perl is harder to learn =
than PHP.
> What can I tell them? That it is not true?
> Yes, but you may or may not be right. We all agree that coming =
into perl is confusing - too much old data about how to do=20
> things is out there in the world. That makes it harder to learn - =
not because the language is harder to learn - but because its not clear =
what the proper way to learn it is.

I've seen that the newbies always want recommendations, and think =
that there should be a recommended way of doing things, a best way.
Well, there is no such thing for perl. Perl is not a language, but =
it is more languages.
If a programmer uses Catalyst and DBIx::Class and HTML::FormFu there =
is a language, if he uses CGI::Application and Rose::DB::Object it is =
another language, if he uses CGI.pm is another one, and there may appear =
other differences if they use mod_perl or fastcgi or just CGI, or if =
they use classic OOP or Moose, Template-Toolkit or Mason.

It is not bad that we can choose, but the beginners don't know what =
to choose, and finally they would find all these confusing and start =
using RoaR or PHP.

> Of course that I could have told them that for real good big =
projects, perl is easier to use than PHP, but most of the PHP users =
don't=20
> care about that kind of projects. They care about simple projects =
created from scratch, that don't even use a web framework or an=20
> ORM or a form processor.
> Sounds like the people who buy expensive fixed-lense cameras, then =
the moment they get interested in photography discover that they could=20
> have bought an SLR, more capable and flexible, for the same price. =
But they swore they didn't need the capability to do that when they >=20
> bought the original cameras, so now they're screwed.

Not exactly, because most of the PHP programmers don't work for =
themselves, but for other clients, and yes, they would find that they =
are scrued if they would need to update a program, but the really scrued =
is the client, because the programmers will ask more money for upgrading =
that software, because they would need more programmers to do it.
The good news is that some software companies started to see that this =
is a problem and don't consider PHP a great idea anymore.
The bad news is that those software companies start to use more and =
more DotNet and Java, and don't even think to Perl, because they know =
that perl is harder to maintain, that perl is write-only and other =
things like these.

Yes, Perl 4 style of programming, or using CGI.pm might create code =
which is harder to maintain, but there isn't a big software company that =
promotes perl and tell them that this is not true anymore.
Octavian

------=_NextPart_000_0186_01C9ADA6.387ECBE0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

ï»=BF

Re: decline and fall of modperl?

This is a multi-part message in MIME format.
--------------010006010205080604030405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Octavian Râşniţă wrote:
> *From:* David Ihnen
>
>
>> > I tried to convince some programmers that Perl is better than
>> PHP, but without any success.
> > How could they know, if they have never used it? I was far less
> convinced that PHP was a blight on the face of scripting science
> until I got a
> > job working in it, after all.
>
> They know it because everybody tell them so. Most web sites are done
> in PHP, most job offer for web programmers ask for PHP experience...
Then they don't know, they just repeat what others say. So I guess all
we can do is repeat what we know from experience, and hope that others
repeat it too...?
>
> > Pay them to do it in perl, and after they get through the
> learning curve they'll probably be much happier with it.
>
> I can't tell that in my country there are no software companies
> specialized in perl programming because I don't know all the software
> companies, but if there are some, they could be counted on fingers,
> and they aren't probably very big.
> So who should pay those PHP programmers in order to motivate them?
Somebody who wants a program, and is smart enough to know that the
engineers are better choosers of the software language than they are.
Any consultant, firm, company, consultant, or contractor can pay, and
spend his time, to learn perl. They simply have to make the decision to
do so. Perhaps you could do so.
>
>> Can perl programs run on share hosting web sites? There are some
>> such hosting companies that don't even offer perl support, and
>> those who offer it, offer just the standard Perl distribution,
>> which don't offer a web framework, or templating systems, or
>> ORMS, or form processors, and in these conditions I can't tell
>> that perl is so great.
> Isn't that to the denigration of the hosting company? Not
> supporting the framework is no way to support your user base. As
> long as the dollar is more important than the feature, there's not
> much we can do about this. These are not things that should be
> built into the core distribution of a language, its the main
> reason PHP is so awful.
>
> I agree that those things shouldn't be built in the core distribution,
> but there could be more distributions, like the one offered by
> ActiveState, or Strawberry Perl or others, just as the Zend PHP
> distribution contains the Zend Framework.
>
> It could be helpful to have a perl distribution that includes the
> latest versions of Template-Toolkit, HTML::Template, Mason, Catalyst,
> CGI::Application, DBIx::Class, Moose, HTML::FormFu and other helpful
> cpan modules.
> A hosting company may want to install that distribution, and it would
> really offer a much better support than the one offered by PHP.
> Yes, those modules won't be updated frequently, but it would be much
> better than simply a CGI.pm support.
Now you're talking about something that just about anybody (even you)
could do if they put their mind to it, don't you think? Its just
creating a distribution, after all. Its just not a very perlish thing
to do to limit. Maybe it would be cool if you could have an interface
that lets you request and install the latest CPAN module on the shared
servers without having root or shell. It might be even better, not
limiting anything.
>
> > Can they hide the source code? (Because who knows who can get it
> from those free hosting web sites)
> > Who cares? Hiding source code is valueless.
>
> Maybe in your country. In my country 10 euro means too much and
> actually even 1 euro means too much if the same thing can be got for
> free, legally or not.
You taking it and using it doesn't impact anything, and the companies
have to understand that. Its just some ideas and organization,
pretending you can keep other people from knowing how you did something
just makes it less supportable by anybody - good software can be bad
software just because its obfuscated like that. Those who matter will
actually pay for your software because they want the support and
customization that comes with it. If they're not going to pay up front,
they're more likely to pay later - keeping them from using the software
at all won't help. So why obfuscate or worry about it?
>
>> > I found that they can hide it, but only after installing Open
>> SSL and a perl module, which they can't do, because those sites
>> don't offer > root access and neither shell access.
> > You get what you pay for I guess.
>
> Well, they can get a free support offered for Zend Optimizer (or how
> it is called the Zend Decoder).
Free support as in open-source community stuff? Or as in a commercial
company spending their time to help you with something that they don't
get paid for?
>
>> In order to show them how good is perl, I told them that they
>> would need to have a dedicated server, or a VPS, but the cheapest
>> VPS costs much more than a shared hosting solution, so in this
>> case perl has another disadvantage.
> If they care that much about a few $ on a monthly fee for their
> web site, they're not going to pay enough to get a skilled
> programmer in ANY language, to do the programming.
>
> Of course they care. If the same thing can be done cheaper using PHP,
> they will surely choose PHP.
> (The quality doesn't matter, because here the things are so fast
> changing, and the easiness of maintenance doesn't matter for most,
> because who knows what will happen after a few years.
Experience says in a few years, you'll want to augment and enhance your
application. But they don't have the experience, eh? Well, if they
want throw-away programs they'll get throw-away programs. And have to
pay for them over and over again. The savings are false. The companies
who chose wisely will get further. But that is a subtle pressure in the
market - perhaps even less so than the idea being implemented - thus
making our advocacy more or less moot. A working program is all that
matters to an end user, not a good or badly engineered program. How can
we convince them that the underlying engineering is important? Short of
organized crime techniques at least. >:)
>
>> > They've also told me that they know that perl is harder to
>> learn than PHP.
>> > What can I tell them? That it is not true?
>> > Yes, but you may or may not be right. We all agree that coming
>> into perl is confusing - too much old data about how to do
>> > things is out there in the world. That makes it harder to
>> learn - not because the language is harder to learn - but because
>> its not clear what the proper way to learn it is.
>
> I've seen that the newbies always want recommendations, and think that
> there should be a recommended way of doing things, a best way.
Do you think there is a way to stop them from thinking that?
> Well, there is no such thing for perl. Perl is not a language, but it
> is more languages.
> If a programmer uses Catalyst and DBIx::Class and HTML::FormFu there
> is a language, if he uses CGI::Application and Rose::DB::Object it is
> another language, if he uses CGI.pm is another one, and there may
> appear other differences if they use mod_perl or fastcgi or just CGI,
> or if they use classic OOP or Moose, Template-Toolkit or Mason.
>
> It is not bad that we can choose, but the beginners don't know what to
> choose, and finally they would find all these confusing and start
> using RoaR or PHP.
Which is a state but not a solution. Are we supposed to agree on a
'best in class solution pattern' and advertise/promote it on sites like
perl.org as a way to counteract the 'too many options' indecisive nature
of humanity?

>> > Of course that I could have told them that for real good big
>> projects, perl is easier to use than PHP, but most of the PHP
>> users don't
>> > care about that kind of projects. They care about simple
>> projects created from scratch, that don't even use a web
>> framework or an
>> > ORM or a form processor.
> > Sounds like the people who buy expensive fixed-lense cameras,
> then the moment they get interested in photography discover that
> they could
> > have bought an SLR, more capable and flexible, for the same
> price. But they swore they didn't need the capability to do that
> when they >
> > bought the original cameras, so now they're screwed.
>
> Not exactly, because most of the PHP programmers don't work for
> themselves, but for other clients
Now you're getting down the fundamental risk levels. The bad programmer
is a risk to his employer, not to himself. This is a very interesting
pattern in our economy.
> , and yes, they would find that they are scrued if they would need to
> update a program, but the really scrued is the client, because the
> programmers will ask more money for upgrading that software, because
> they would need more programmers to do it.
So its not the programmer in the end that made the bad decision, its the
client? Yet, the client trusted the programmer to choose a technology.
There's something afoul here. There can be no evolution to better
programmers because the badness of the programmer has almost no effect
on the decision.
> The good news is that some software companies started to see that this
> is a problem and don't consider PHP a great idea anymore.
Thank Dog. Now to get that pattern more widespread. Ideas?
> The bad news is that those software companies start to use more and
> more DotNet and Java, and don't even think to Perl, because they know
> that perl is harder to maintain, that perl is write-only and other
> things like these.
But they don't even really know. Do they know they don't know?
> Yes, Perl 4 style of programming, or using CGI.pm might create code
> which is harder to maintain, but there isn't a big software company
> that promotes perl and tell them that this is not true anymore.
By this I assume you mean that you have to be 'big' in order to have any
credibility in choosing your technology?

David


--------------010006010205080604030405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit








Octavian Râşniţă wrote:

type="cite">

From: title="davidi@norchemlab.com" href="mailto:davidi@norchemlab.com">David
Ihnen

type="cite">
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

 

type="cite">

> I tried to convince some
programmers that Perl is better than PHP, but without any success.

> How could they know, if they have never used it?  I was
far less convinced that PHP was a blight on the face of scripting
science until I got a

> job working in it, after all.

type="cite">
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

> Pay them to do it in perl, and after they get through the
learning curve they'll probably be much happier with it.

type="cite">
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

type="cite">

Can perl programs run on share
hosting web sites? There are some such hosting companies that don't
even offer perl support, and those who offer it, offer just the
standard Perl distribution, which don't offer a web framework, or
templating systems, or ORMS, or form processors, and in these
conditions I can't tell that perl is so great.

Isn't that to the denigration of the hosting company?  Not
supporting the framework is no way to support your user base.  As long
as the dollar is more important than the feature, there's not much we
can do about this.  These are not things that should be built into the
core distribution of a language, its the main reason PHP is so awful.

encrypting perl

Octavian Râsnita wrote:
> The actual perl programmers are not important, because they already have
> their reasons for using perl.
> Are you saying that nobody uses Zend Encoder because PHP also runs using
> an interpreter?

I'm changing the topic of your discussion because it's gone tangent to
the subject...

Business people love the idea of their intellectual property (IP) being
protected by way of code encryption. Try telling them their money-making
code is 'in the open, but everyone's doing it too'. Not exactly a warm
fuzzy feeling.

This topic has been resurfaced from time to time. I think the bottom
line is: there is no supported form of code encryption for Perl. Some
people try to partially compile the code into bytecode, and distribute
with that. But I don't think it's officially supported.

The forward step in this may lie with Perl6. Unfortunately while Parrot
1.0 has JUST been launched, Perl6 isn't, and it'd take quite a while
before we get there. It's still NOT encoded, just compiled into a more
cryptic form, just like Java and the rest.

Re: decline and fall of modperl?

David Ihnen wrote:
> I think you've got it right there. We've got to get perl taught in
> schools. That means perl experts need to be in teaching. And I have a
> suspicion that perl doesn't appeal to the pure computer scientist very
> well - these are the people who invented hard typed languages, after all.
In the academia the general directive in choosing a language would be
something to this effect:
1. teach modern language concepts, such as OO
2. minimise the learning curve by way of something easy to teach, easy
to learn without having to figure out all the details of programming
3. introduce the students to a language that will make them attractive
to the general market

You probably have a feel why Perl isn't a strong choice given these
objectives.

Perl was popular in the days when the people who go into software
courses do it for the sake of pure interest. These are the people who
are contented with Emacs or VIM, as long as they get to work with the codes.

Half of today's CompSci students are people who stumble in because they
haven't figured things out in life. The problem is made worse by Visual
Studio and Eclipse. I remember how Java was a painful experience before
someone finally put up a IDE that aids code visualisation and object
description.

My personal belief is that Perl MUST move with the times. It's an
incredibly uphill task to change the market's mindset without a
commercial budget.

I place my bets on Perl6. It's regrettably a slow process, but it's the
only sexy thing available on hand.

> Pay them to do it in perl, and after they get through the learning curve
> they'll probably be much happier with it.
Half the developers aren't the type who can appreciate a good language.
They can develop intensively for 5 years and they STILL haven't figured
out what is Regex. Trust me on this!

> Who cares? Hiding source code is valueless.
You haven't met the China folks have you? :)

There's outright protection, there's deterrance, and there's leaving the
door open for every bad boy to muck it up.

Re: decline and fall of modperl?

--001485ecf70a71499304660324b6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Foo JH wrote:
> In the academia the general directive in choosing a language would be
> something to this effect:
> 1. teach modern language concepts, such as OO
> 2. minimise the learning curve by way of something easy to teach, easy
> to learn without having to figure out all the details of programming
> 3. introduce the students to a language that will make them attractive
> to the general market
>
> You probably have a feel why Perl isn't a strong choice given these
> objectives.

On points 1 & 2:
1. Perl supports more programming paradigms than Java.
2. You write fewer lines of perl to get things done than you do in Java.

There is empirical evidence of this - anyone seen the Software Productivity
Group research on programming languages? In general:

C - 6 x more productive than assembler
Java/C++ - 3 x more productive than C
Perl/Python (Ruby/javascript not represented) - 2-3 x more productive than
Java/C++

Results are consistent over 2 studies a decade or so apart.

Point 3 does scream "Java" but take a look at this:

http://lambda-the-ultimate.org/node/2941

The author laments the ubiquity of Java as the language of choice in
education (despite having advocated it himself). On balance he'd go for
python but doesn't dismiss Perl out of hand either.

I can't convince my own colleagues of the benefits of perl despite the fact
I continually produce decent quality s/w faster than they can, when given
the opportunity. Folk will see what they expect to see.

This was demonstrated by a psychology experiment in the 90's. Subjects were
asked to look at a video of 2 football teams passing a football around and
count how many times the ball was passed.

When asked at the end of the video the answers were pretty accurate. Then
they were asked "What about the gorilla?". In the middle of the video
someone in a gorilla suit walks on, bangs on its chest and walks off. Hardly
anyone spots the gorilla.

--001485ecf70a71499304660324b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Foo JH wrote:
> In the academia the general directive in choosing a l=
anguage would be

> something to this effect:

> 1. teach modern language concepts, such as OO

> 2. minimise the learning curve by way of something easy to teach, easy=


> to learn without having to figure out all the details of programming r>
> 3. introduce the students to a language that will make them attractive=


> to the general market

>

> You probably have a feel why Perl isn't a strong choice given thes=
e

> objectives.

On points 1 & 2:
1. Perl supports more progr=
amming paradigms than Java.
2. You write fewer lines of perl to get thin=
gs done than you do in Java.

There is empirical evidence of this - a=
nyone seen the Software Productivity Group research on programming language=
s? In general:




C - 6 x more productive than assembler

Java/C++ - 3 x more productive than C

Perl/Python (Ruby/javascript not represented) - 2-3 x more productive than =
Java/C++



Results are consistent over 2 studies a decade or so apart.

Point 3 =
does scream "Java" but take a look at this:

p://lambda-the-ultimate.org/node/2941">http://lambda-the-ult imate.org/node/=
2941


The author laments the ubiquity of Java as the language of choice in ed=
ucation (despite having advocated it himself). On balance he'd go for p=
ython but doesn't dismiss Perl out of hand either.

I can't c=
onvince my own colleagues of the benefits of perl despite the fact I contin=
ually produce decent quality s/w faster than they can, when given the oppor=
tunity. Folk will see what they expect to see.


This was demonstrated by a psychology experiment in the 90's. Subje=
cts were asked to look at a video of 2 football teams passing a football ar=
ound and count how many times the ball was passed.

When asked at the=
end of the video the answers were pretty accurate. Then they were asked &q=
uot;What about the gorilla?". In the middle of the video someone in a =
gorilla suit walks on, bangs on its chest and walks off. Hardly anyone spot=
s the gorilla.




--001485ecf70a71499304660324b6--

Re: decline and fall of modperl?

From: "David Ihnen"
>> They know it because everybody tell them so. Most web sites are done=20
>> in PHP, most job offer for web programmers ask for PHP experience...
> Then they don't know, they just repeat what others say. So I guess =
all=20
> we can do is repeat what we know from experience, and hope that others =

> repeat it too...?

Yes of course, but I usually receive responses like "oh, perl, that ugly =
language? Python's much nicer and Ruby too. Can you do with perl what =
you can do with Python?"
And I know that there is a screen reader for Windows and another one for =
Linux/Solaris which is made in Python, but it would be much harder to do =
the same thing with perl, so I can't say anything.
I think that Perl is the best for web programming and system admins, but =
Python is better for interacting with the operating systems, especially =
with Windows, and with programs made in DotNet and Java.

>> So who should pay those PHP programmers in order to motivate them?
> Somebody who wants a program, and is smart enough to know that the=20
> engineers are better choosers of the software language than they are. =


I don't know too many companies of this kind...
And finally, the management of those companies could tell "ok, let's use =
Perl", but they will find that there are no perl programmers available, =
so they'll be convinced that perl is a language which is not used very =
much in these days, and that it would cost them more if they would like =
to create perl programs.

>> > Who cares? Hiding source code is valueless.
>>
>> Maybe in your country. In my country 10 euro means too much and=20
>> actually even 1 euro means too much if the same thing can be got for=20
>> free, legally or not.
> You taking it and using it doesn't impact anything, and the companies=20
> have to understand that. Its just some ideas and organization,=20
> pretending you can keep other people from knowing how you did =
something=20
> just makes it less supportable by anybody - good software can be bad=20
> software just because its obfuscated like that. Those who matter will =

> actually pay for your software because they want the support and=20
> customization that comes with it. If they're not going to pay up =
front,=20
> they're more likely to pay later - keeping them from using the =
software=20
> at all won't help. So why obfuscate or worry about it?

Because the clients pay once when they receive the program, and because =
the programmers usually don't trust their clients.
They think that the IT guys of the client could just get the program, =
change it and sell it to another company.

>> > You get what you pay for I guess.
>>
>> Well, they can get a free support offered for Zend Optimizer (or how=20
>> it is called the Zend Decoder).
> Free support as in open-source community stuff? Or as in a commercial =

> company spending their time to help you with something that they don't =

> get paid for?

Zend is paid for, because they offer the Zend Optimizer for free and ask =
for money just for the Zend Encoder, so those programmers that want =
protection should buy it from Zend, but if they want this, they could =
have support for it from the hosting companies.
A perl programmer doesn't need to pay for Filter::Crypto. He could use =
it for free, but the hosting companies won't offer support for it.

>> Of course they care. If the same thing can be done cheaper using PHP, =

>> they will surely choose PHP.
>> (The quality doesn't matter, because here the things are so fast=20
>> changing, and the easiness of maintenance doesn't matter for most,=20
>> because who knows what will happen after a few years.
> Experience says in a few years, you'll want to augment and enhance =
your=20
> application. But they don't have the experience, eh? Well, if they=20
> want throw-away programs they'll get throw-away programs. And have to=20
> pay for them over and over again. The savings are false. The =
companies=20
> who chose wisely will get further. But that is a subtle pressure in =
the=20
> market - perhaps even less so than the idea being implemented - thus=20
> making our advocacy more or less moot. A working program is all that=20
> matters to an end user, not a good or badly engineered program. How =
can=20
> we convince them that the underlying engineering is important? Short =
of=20
> organized crime techniques at least. >:)

That's true. The languages that don't require wiseness for beeing =
appreciated have a big advantage these days.
Without wiseness, perl can't be appreciated, and this is a big minus, =
because these days there are much more programmers and much more =
applications users than 15 years ago, and the inteligence level of all =
the programmers of the world decreases if the number of them increases.

>> I've seen that the newbies always want recommendations, and think =
that=20
>> there should be a recommended way of doing things, a best way.
> Do you think there is a way to stop them from thinking that?

Yes, by offering them not a single solution like Python pretends to do, =
but a few solutions, with recommendations for each solution.
Perl offers an infinite number of solutions and it is harder to test =
them all and choose what's the best.
For the same reason it is hard to find a team of perl programmers that =
know the same modules and have the same style of programming, use the =
same editors...

>> Well, there is no such thing for perl. Perl is not a language, but it =

>> is more languages.
>> If a programmer uses Catalyst and DBIx::Class and HTML::FormFu there=20
>> is a language, if he uses CGI::Application and Rose::DB::Object it is =

>> another language, if he uses CGI.pm is another one, and there may=20
>> appear other differences if they use mod_perl or fastcgi or just CGI, =

>> or if they use classic OOP or Moose, Template-Toolkit or Mason.
>> =20
>> It is not bad that we can choose, but the beginners don't know what =
to=20
>> choose, and finally they would find all these confusing and start=20
>> using RoaR or PHP.
> Which is a state but not a solution. Are we supposed to agree on a=20
> 'best in class solution pattern' and advertise/promote it on sites =
like=20
> perl.org as a way to counteract the 'too many options' indecisive =
nature=20
> of humanity?

Not just a single solution, but 3, 4, 5, but not an infinite number of =
solutions.
After the beginner would read the recommendations for all those few =
solutions, they would be able to choose one, and start using it, and =
then they'll understand that they can mix those solutions and create =
another one prefered by them, because this wouldn't be a problem after =
they would know Perl better.
Shorter said, perl is not very much targeted to the beginners.

>> Not exactly, because most of the PHP programmers don't work for=20
>> themselves, but for other clients
> Now you're getting down the fundamental risk levels. The bad =
programmer=20
> is a risk to his employer, not to himself. This is a very interesting =

> pattern in our economy.

Yes, long time risk. And the problem is that some companies are warned =
and know about this risk, but prefer to take it, because some economies =
are fragile and the short time costs are more important than the long =
time ones.

> So its not the programmer in the end that made the bad decision, its =
the=20
> client? Yet, the client trusted the programmer to choose a =
technology. =20
> There's something afoul here. There can be no evolution to better=20
> programmers because the badness of the programmer has almost no effect =

> on the decision.

Yes, the client decides, and that's why languages like PHP are prefered.
But there are other reasons for what other languages like Python are =
prefered.
There might be more reasons, but some I've seen are: the fact that =
Python's OOP default style is much better than perl's one, the fact that =
Python could interact better with programs made in other languages like =
Java, the fact that most users consider Python's syntax more clear than =
perl's syntax, the fact that Python has some good modules that are very =
helpful under Windows...
Most perl programmers consider Windows a bad OS, consider that Perl's =
web services shouldn't be necessarily compatible with those of Java or =
DotNet, don't care about low end users that need to use free web hosting =
companies... and this doesn't mean that it is bad, but it limits very =
much the target of this language, so we can say that perl is the best, =
but only for a very small number of developers.

>> The good news is that some software companies started to see that =
this=20
>> is a problem and don't consider PHP a great idea anymore.
> Thank Dog. Now to get that pattern more widespread. Ideas?

Promoting this would be very hard, because there is a big market for PHP =
applications, so even if they know that PHP is not a great language, =
they know that they can find easy PHP programmers for employing them, so =
it won't cost them too much, and that they would also find clients for =
those applications.

>> The bad news is that those software companies start to use more and=20
>> more DotNet and Java, and don't even think to Perl, because they know =

>> that perl is harder to maintain, that perl is write-only and other=20
>> things like these.
> But they don't even really know. Do they know they don't know?

I don't really know if they know, but I think that most of them don't =
really care.
This is because they know that storing perl applications costs more than =
storing PHP applications, and they would find fewer clients, and the =
most important, they know that they can't find perl programmers very =
easy.

>> Yes, Perl 4 style of programming, or using CGI.pm might create code=20
>> which is harder to maintain, but there isn't a big software company=20
>> that promotes perl and tell them that this is not true anymore.
> By this I assume you mean that you have to be 'big' in order to have =
any=20
> credibility in choosing your technology?

Absolutely. I've seen companies that bought an Oracle database not =
because they really needed it, but because they heard that "Oracle is =
the best", and because the software companies distribute Oracle for a =
good commision, so they promote Oracle and not PostgreSQL or something =
else.
I don't know if Zend also makes this kind of arrangements with their =
corporate clients, but it could be possible...

Octavian

Re: encrypting perl

From: "Foo JH"
> Business people love the idea of their intellectual property (IP) =
being
> protected by way of code encryption. Try telling them their =
money-making
> code is 'in the open, but everyone's doing it too'. Not exactly a warm
> fuzzy feeling.
>=20
> This topic has been resurfaced from time to time. I think the bottom
> line is: there is no supported form of code encryption for Perl. Some
> people try to partially compile the code into bytecode, and distribute
> with that. But I don't think it's officially supported.
>=20
> The forward step in this may lie with Perl6. Unfortunately while =
Parrot
> 1.0 has JUST been launched, Perl6 isn't, and it'd take quite a while
> before we get there. It's still NOT encoded, just compiled into a more
> cryptic form, just like Java and the rest.
>

I think it would be enough, because there will surely be added other =
ways for obfuscating the code, and if the OOP style will be more clear =
and easier to use than it is now, Perl 6 would have some chances.

Octavian

To learn perl... [was: decline and fall of modperl?]

On 25 Mar 2009, at 18:23, David Ihnen wrote:

>> They've also told me that they know that perl is harder to learn
>> than PHP.
>> What can I tell them? That it is not true?
> Yes, but you may or may not be right. We all agree that coming into
> perl is confusing - too much old data about how to do things is out
> there in the world. That makes it harder to learn - not because the
> language is harder to learn - but because its not clear what the
> proper way to learn it is.

And what is the proper way? I've futzed about in a number or languages
- including perl - but only at a very basic level with perl. I've got
some web stuff to do and thought that having a go with perl may be a
pleasant diversion. At the moment it looks like I'll be using Catalyst
and Mason to help with the job - but what are the pratfalls to avoid -
or the good practice to follow (use strict and warnings :-)

As an outsider, perl is its own worst enemy. Its proud boast is that
there's more than one way of doing things (so show me a language where
that's not true) while not really showing a good way. I accept that a
chunk of this is style / taste / choice but a few pointers along the
lines of "that way the road is quite straight and smooth" would help
quite a lot.

I guess I'm asking for a magic formula which doesn't exist and that I
should just bloody well get on and do it but I'll ask anyway.

TIA

Simon

Re: To learn perl... [was: decline and fall of modperl?]

On 26 Mar 2009, at 11:35, Simon Forster wrote:
>
> And what is the proper way? I've futzed about in a number or
> languages - including perl - but only at a very basic level with
> perl. I've got some web stuff to do and thought that having a go
> with perl may be a pleasant diversion. At the moment it looks like
> I'll be using Catalyst and Mason to help with the job - but what are
> the pratfalls to avoid - or the good practice to follow (use strict
> and warnings :-)
>
> As an outsider, perl is its own worst enemy. Its proud boast is that
> there's more than one way of doing things (so show me a language
> where that's not true) while not really showing a good way. I accept
> that a chunk of this is style / taste / choice but a few pointers
> along the lines of "that way the road is quite straight and smooth"
> would help quite a lot.
>
> I guess I'm asking for a magic formula which doesn't exist and that
> I should just bloody well get on and do it but I'll ask anyway.

There's been some recognition of this fact among long standing perl
developers and there's probably
two main answers.

The older answer is something along the lines of "Perl Best Practice"
the O'Reilly
book by D. Conway and ideas behind it. See also http://www.perl.com/pub/a/2005/07/14/bestpractices.html
..

The newer answer is an emerging buzzword called "Modern Perl" or
sometimes "Enlightened Perl".
Chromatic's blog on the subject, http://www.modernperlbooks.com/mt/,
is probably the best
starting place for that idea.

- Mark

Re: To learn perl... [was: decline and fall of modperl?]

--001636c5ad4d3588ec0466043d8c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Mar 26, 2009 at 11:35 AM, Simon Forster wrote:

>
> On 25 Mar 2009, at 18:23, David Ihnen wrote:
>
> They've also told me that they know that perl is harder to learn than PHP.
>>> What can I tell them? That it is not true?
>>>
>> Yes, but you may or may not be right. We all agree that coming into perl
>> is confusing - too much old data about how to do things is out there in the
>> world. That makes it harder to learn - not because the language is harder
>> to learn - but because its not clear what the proper way to learn it is.
>>
>
> And what is the proper way? I've futzed about in a number or languages -
> including perl - but only at a very basic level with perl. I've got some web
> stuff to do and thought that having a go with perl may be a pleasant
> diversion. At the moment it looks like I'll be using Catalyst and Mason to
> help with the job - but what are the pratfalls to avoid - or the good
> practice to follow (use strict and warnings :-)
>
> As an outsider, perl is its own worst enemy. Its proud boast is that
> there's more than one way of doing things (so show me a language where
> that's not true) while not really showing a good way. I accept that a chunk
> of this is style / taste / choice but a few pointers along the lines of
> "that way the road is quite straight and smooth" would help quite a lot.
>
> I guess I'm asking for a magic formula which doesn't exist and that I
> should just bloody well get on and do it but I'll ask anyway.
>
> TIA
>
> Simon
>

"The Perl Cookbook" will likely as not point you at the smoother parts of
the road.
"Perl Best Practices" by Damian Conway goes into the "right" way to do
perl-ish things in great depth.
PerlCritic is a perl module inspired by the book that will check your code
against a configured policy set.
A great place to start is the Camel book ("Programming Perl" - Wall et al)
which has sections on style, newbie pitfalls etc

Try "Perl Hacks" for a more sideways glance.

It is a rich, flexible, language that has been around a good while. In a
good few years at this game I have not come across another that gets you
from here to there in so few steps.

--001636c5ad4d3588ec0466043d8c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Re: decline and fall of modperl?

hey

On 3/25/2009 11:24 PM, Foo JH wrote:
> You probably have a feel why Perl isn't a strong choice given these
> objectives.

hmm ... i'm not sure about your second point. it's a somewhat arbitrary
example, but look at a 'hello world' in several languages. perl is
definitely on the easy side to teach [and understand].

of course, once you get to TMTOWTDI, it's like teaching creative writing ...

> There's outright protection, there's deterrance, and there's leaving the
> door open for every bad boy to muck it up.

well, sometimes leaving the door open means that someone else will fix
something too. it does happen that the glass is half full sometimes ...

--
\js

Re: To learn perl... [was: decline and fall of modperl?]

On 26 Mar 2009, at 11:50, Mark Blackman wrote:

> The older answer is something along the lines of "Perl Best
> Practice" the O'Reilly
> book by D. Conway and ideas behind it. See also http://www.perl.com/pub/a/2005/07/14/bestpractices.html
> .
>
> The newer answer is an emerging buzzword called "Modern Perl" or
> sometimes "Enlightened Perl".
> Chromatic's blog on the subject, http://www.modernperlbooks.com/mt/,
> is probably the best
> starting place for that idea.


On 26 Mar 2009, at 11:51, Rolf Banting wrote:

> "The Perl Cookbook" will likely as not point you at the smoother
> parts of the road.
> "Perl Best Practices" by Damian Conway goes into the "right" way to
> do perl-ish things in great depth.
> PerlCritic is a perl module inspired by the book that will check
> your code against a configured policy set.
> A great place to start is the Camel book ("Programming Perl" - Wall
> et al) which has sections on style, newbie pitfalls etc
>
> Try "Perl Hacks" for a more sideways glance.
>
> It is a rich, flexible, language that has been around a good while.
> In a good few years at this game I have not come across another that
> gets you from here to there in so few steps.

Sheesh. Thanks guys but I don't have enough time to digest all that.

;-)

Probably I should just buy the Camel book - but it's a bit long in the
tooth now (perl 5.6, published 2000).

I imagine I'll just throw myself into it at some time and bore the
list with asinine questions.

Simon

Re: To learn perl... [was: decline and fall of modperl?]

--001636c5bbd11ed98e0466057ed2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Mar 26, 2009 at 1:04 PM, Simon Forster wrote:

>
> On 26 Mar 2009, at 11:50, Mark Blackman wrote:
>
> The older answer is something along the lines of "Perl Best Practice" the
>> O'Reilly
>> book by D. Conway and ideas behind it. See also
>> http://www.perl.com/pub/a/2005/07/14/bestpractices.html.
>>
>> The newer answer is an emerging buzzword called "Modern Perl" or sometimes
>> "Enlightened Perl".
>> Chromatic's blog on the subject, http://www.modernperlbooks.com/mt/, is
>> probably the best
>> starting place for that idea.
>>
>
>
> On 26 Mar 2009, at 11:51, Rolf Banting wrote:
>
> "The Perl Cookbook" will likely as not point you at the smoother parts of
>> the road.
>> "Perl Best Practices" by Damian Conway goes into the "right" way to do
>> perl-ish things in great depth.
>> PerlCritic is a perl module inspired by the book that will check your code
>> against a configured policy set.
>> A great place to start is the Camel book ("Programming Perl" - Wall et al)
>> which has sections on style, newbie pitfalls etc
>>
>> Try "Perl Hacks" for a more sideways glance.
>>
>> It is a rich, flexible, language that has been around a good while. In a
>> good few years at this game I have not come across another that gets you
>> from here to there in so few steps.
>>
>
> Sheesh. Thanks guys but I don't have enough time to digest all that.
>
> ;-)
>
> Probably I should just buy the Camel book - but it's a bit long in the
> tooth now (perl 5.6, published 2000).
>
> I imagine I'll just throw myself into it at some time and bore the list
> with asinine questions.
>
> Simon
>

Fair enough Simon. I would recommend you look at the Cookbook too - it has
recipes for everything from iterating through a hash to web automation.

http://docstore.mik.ua/orelly/perl/cookbook/

Slan abhaile,

Rolf

--001636c5bbd11ed98e0466057ed2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Re: decline and fall of modperl?

On Thu, 26 Mar 2009 08:55:45 -0400, john saylor
wrote:

> of course, once you get to TMTOWTDI, it's like teaching creative writing

And thus, the beauty of it. :)

--
ispy++

Re: decline and fall of modperl?

This is a multi-part message in MIME format.

------=_NextPart_000_003A_01C9AE3A.87C01B20
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

From: Rolf Banting=20
Foo JH wrote:
> In the academia the general directive in choosing a language would =
be
> something to this effect:
> 1. teach modern language concepts, such as OO
> 2. minimise the learning curve by way of something easy to teach, =
easy
> to learn without having to figure out all the details of programming
> 3. introduce the students to a language that will make them =
attractive
> to the general market
>
> You probably have a feel why Perl isn't a strong choice given these
> objectives.

> On points 1 & 2:
> 1. Perl supports more programming paradigms than Java.
> 2. You write fewer lines of perl to get things done than you do in =
Java.

1. I don't know what it means that perl supports more paradigms than =
Java, but I know that the Java / C# OOP style is usually considered a =
much complete and better standard than one used by Perl.
Java / DotNet support interfaces, so the classes they create respect =
the "contracts" better, while in perl world, the programmer is free, and =
nobody points a shotgun to him in order to force him to do it.

Java and C# uses a dot notation for separating the classes when using =
the OOP style, and even Template-Toolkit uses it, but perl uses =
something else.

2. It is right that perl is probably one of the most productive =
languages, because it requires to write very little code, for doing very =
many things.
But for doing the same thing, Ruby and Python can use sometimes even =
less code, because they don't use so much punctuation and funny chars.

And anyway, for the beginners, this is not a big problem. The biggest =
problem is that perl is harder to learn. The programmers might want to =
learn a language for a year, and get a job, and after this they hope =
that they will find time to learn the chosen language better while they =
have a job.

We could say that perl would be really great for these days if we =
could say about it something like:
- It is the most easy to learn language even by the most stupid =
programmers.
- It can create portable programs that can run everywhere, under =
Windows, Mac, Linux, shared hosting web sites that don't offer root and =
shell access...
- The source code of the programs can be hidden.
- There are very many recent books that teach Perl.
- Perl is chosen by bigger companies like IBM, Oracle, Microsoft, Sun, =
Yahoo, Google, SAP.
- The popular sites like Twitter, Digg, Facebook, MySpace, Wikipedia, =
are powered by perl.
- There are important other software made in Perl which are used much =
these days, like a mailing list manager, a web server, financial =
charting software, stock exchange trading applications, etc.

...and other things like these. But unfortunately in the last years =
I've seen only reports about the decreasing number of sites that use =
Perl.

Octavian

------=_NextPart_000_003A_01C9AE3A.87C01B20
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable



charset=3Diso-8859-1">

Re: decline and fall of modperl?

This is a multi-part message in MIME format.
--------------090308030705080108070303
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Foo JH wrote:
> David Ihnen wrote:
>
>> I think you've got it right there. We've got to get perl taught in
>> schools. That means perl experts need to be in teaching. And I have a
>> suspicion that perl doesn't appeal to the pure computer scientist very
>> well - these are the people who invented hard typed languages, after all.
>>
> In the academia the general directive in choosing a language would be
> something to this effect:
> 1. teach modern language concepts, such as OO
> 2. minimise the learning curve by way of something easy to teach, easy
> to learn without having to figure out all the details of programming
> 3. introduce the students to a language that will make them attractive
> to the general market
>
> You probably have a feel why Perl isn't a strong choice given these
> objectives.
>
1. Perl does OO quite well.

2. Perl doesn't force you to learn all about typing and match all that
together, which is admittedly what gives me the biggest problems in
typed languages (admittedly because i'm such a experienced loosely typed
programmer) Thus making the language a shorter learning curve, IMO. A
misplaced ; is as much a problem in most any language, for details.

3. The general market will find perl more attractive with more trained
perl programmers entering the market... if whoever has the most leverage
wins we're dooomed, DOOMED I TELL YOU! no, not really. ;) I want to
see people starting new companies and new technologies with perl,
instead of the likes of Java and PHP. Set up the students to make their
own market - not fit into the slots of the current one - the academia is
always behind the time there.

Maybe it was better when they taught things like Modula-2 - not because
they think you're going to use it in your job - but because you need to
learn the patterns and processes of programming.
> Perl was popular in the days when the people who go into software
> courses do it for the sake of pure interest. These are the people who
> are contented with Emacs or VIM, as long as they get to work with the codes.
>
I suppose we need more programmers than those programmers who are just
interested in coding? I never met a good programmer who wasn't
intrinsically interested in it.
> Half of today's CompSci students are people who stumble in because they
> haven't figured things out in life. The problem is made worse by Visual
> Studio and Eclipse. I remember how Java was a painful experience before
> someone finally put up a IDE that aids code visualisation and object
> description.
>
Do we need to help those half of students into programming? Hm. Wash'm
out!
> My personal belief is that Perl MUST move with the times. It's an
> incredibly uphill task to change the market's mindset without a
> commercial budget.
>
I Agree. Who has the time when not being paid?
> I place my bets on Perl6. It's regrettably a slow process, but it's the
> only sexy thing available on hand.
>
I agree. I have great optomism for perl 6's hit on the market and how
it will refresh the image of perl worldwide.
>> Pay them to do it in perl, and after they get through the learning curve
>> they'll probably be much happier with it.
>>
> Half the developers aren't the type who can appreciate a good language.
> They can develop intensively for 5 years and they STILL haven't figured
> out what is Regex. Trust me on this!
>
*cries* Say it ain't so, man!
>> Who cares? Hiding source code is valueless.
>>
> You haven't met the China folks have you? :)
>
No. What do they do in China with open code like open source code?
> There's outright protection, there's deterrance, and there's leaving the
> door open for every bad boy to muck it up.
>
Being able to analyze and apply a direct fix to code that is
malfunctioning is of such high value that making it impossible is a
serious handicap.

I keep thinking they're ashamed of their code thats why they want to
hide it.

David


--------------090308030705080108070303
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit








Foo JH wrote:

David Ihnen wrote:

  

I think you've got it right there.  We've got to get perl taught in

schools.  That means perl experts need to be in teaching.  And I have a

suspicion that perl doesn't appeal to the pure computer scientist very

well - these are the people who invented hard typed languages, after all.

    

In the academia the general directive in choosing a language would be

something to this effect:

1. teach modern language concepts, such as OO

2. minimise the learning curve by way of something easy to teach, easy

to learn without having to figure out all the details of programming

3. introduce the students to a language that will make them attractive

to the general market



You probably have a feel why Perl isn't a strong choice given these

objectives.

  

Perl was popular in the days when the people who go into software

courses do it for the sake of pure interest. These are the people who

are contented with Emacs or VIM, as long as they get to work with the codes.

  

Half of today's CompSci students are people who stumble in because they

haven't figured things out in life. The problem is made worse by Visual

Studio and Eclipse. I remember how Java was a painful experience before

someone finally put up a IDE that aids code visualisation and object

description.

  

My personal belief is that Perl MUST move with the times. It's an

incredibly uphill task to change the market's mindset without a

commercial budget.

  

I place my bets on Perl6. It's regrettably a slow process, but it's the

only sexy thing available on hand.

  

Pay them to do it in perl, and after they get through the learning curve

they'll probably be much happier with it.

    

Half the developers aren't the type who can appreciate a good language.

They can develop intensively for 5 years and they STILL haven't figured

out what is Regex. Trust me on this!

  

Who cares?  Hiding source code is valueless.

    

You haven't met the China folks have you? :)

  

There's outright protection, there's deterrance, and there's leaving the

door open for every bad boy to muck it up.

  

Re: decline and fall of modperl?

--001636c5a2d90ae2270466090d5a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 26, 2009 at 3:44 PM, Octavian R=E2snita wro=
te:

> *From:* Rolf Banting
>
> Foo JH wrote:
> > In the academia the general directive in choosing a language would be
> > something to this effect:
> > 1. teach modern language concepts, such as OO
> > 2. minimise the learning curve by way of something easy to teach, easy
> > to learn without having to figure out all the details of programming
> > 3. introduce the students to a language that will make them attractive
> > to the general market
> >
> > You probably have a feel why Perl isn't a strong choice given these
> > objectives.
>
> > On points 1 & 2:
> > 1. Perl supports more programming paradigms than Java.
> > 2. You write fewer lines of perl to get things done than you do in Java=
..
> 1. I don't know what it means that perl supports more paradigms than Java=
,
> but I know that the Java / C# OOP style is usually considered a much
> complete and better standard than one used by Perl.
>
> Functions are first class citizens in Perl - so you get functional
programming built in. You don't in Java.

How are standards of OO quantified and compared?

> Java / DotNet support interfaces, so the classes they create respect the
> "contracts" better, while in perl world, the programmer is free, and nobo=
dy
> points a shotgun to him in order to force him to do it.
>
> Java and C# uses a dot notation for separating the classes when using the
> OOP style, and even Template-Toolkit uses it, but perl uses something els=
e.
>
>
> C++ uses '::'

> 2. It is right that perl is probably one of the most productive languages=
,
> because it requires to write very little code, for doing very many things=
..
> But for doing the same thing, Ruby and Python can use sometimes even less
> code, because they don't use so much punctuation and funny char
>
> And anyway, for the beginners, this is not a big problem. The biggest
> problem is that perl is harder to learn. The programmers might want to le=
arn
> a language for a year, and get a job, and after this they hope that they
> will find time to learn the chosen language better while they have a job.
>
> Harder to learn than what? Is there any evidence for this?

>
> We could say that perl would be really great for these days if we could s=
ay
> about it something like:
> - It is the most easy to learn language even by the most stupid
> programmers.
>
> It is easy to learn!

> - It can create portable programs that can run everywhere, under Windows,
> Mac, Linux, shared hosting web sites that don't offer root and shell acce=
ss.
>
> - The source code of the programs can be hidden.
>
> - There are very many recent books that teach Perl.
>
> Why is "recent" important? The language features haven't changed much so
why would the learning resources?

> - Perl is chosen by bigger companies like IBM, Oracle, Microsoft, Sun,
> Yahoo, Google, SAP.
> - The popular sites like Twitter, Digg, Facebook, MySpace, Wikipedia, are
> powered by perl.
> - There are important other software made in Perl which are used much the=
se
> days, like a mailing list manager, a web server, financial charting
> software, stock exchange trading applications, etc.
>
> I know of perl CORBA applications that have been responsible for charging
literally millions of real-time short messages in telecomms networks in
Latin America.

>
> ...and other things like these. But unfortunately in the last years I've
> seen only reports about the decreasing number of sites that use Perl.
>
> Octavian
>
>
> Use of perl is declining - but not due to lack of technical merit. Fashio=
ns
change.

--001636c5a2d90ae2270466090d5a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Is Cookbook good perl?

Rolf Banting wrote:
> Fair enough Simon. I would recommend you look at the Cookbook too - it
> has recipes for everything from iterating through a hash to web
> automation.
>
> http://docstore.mik.ua/orelly/perl/cookbook/
Do people think that the cookbook is good perl practice? Its been
mentioned a few times, and I can't help but wince a bit each time.

Its not like I can put my finger directly on it, but the perl feels...
Old Style and frequently non-optimal in pattern and method.

Like maybe we could combine Damian Conway's Perl Best Practices and
Object Oriented Perl (open on my desk working my way through it!) and
revise Perl Cookbook - providing a 'fresh book for beginners on perl'
that is up to date.

Maybe its planned for Perl 6, I dunno. But I would deposit the opinion
that Cookbook is not the best book to learn from, for the best practices
of perl.

David

Re: Is Cookbook good perl?

On Thu, Mar 26, 2009 at 1:39 PM, David Ihnen wrote:
> Do people think that the cookbook is good perl practice?

Yes, it's an excellent resource and you'll have to pry it from my cold
dead hands. It wouldn't be where I would turn to find out the current
best ORM module, but it is where I would turn to find a whole bunch of
clearly written examples and advice on file locking, network
programming, system interaction, etc.

> Like maybe we could combine Damian Conway's Perl Best Practices and Object
> Oriented Perl

Object Oriented Perl has more "age" issues than the Cookbook, IMO.
It's still an entertaining read, but my advice for newbies would be to
read the OO docs that come with Perl for understanding and then
consider using Moose/Mouse for new projects.

- Perrin

Re: Is Cookbook good perl?

On Thu, 26 Mar 2009 13:53:30 -0400, Perrin Harkins
wrote:

> Object Oriented Perl has more "age" issues than the Cookbook, IMO.
> It's still an entertaining read, but my advice for newbies would be to
> read the OO docs that come with Perl for understanding and then
> consider using Moose/Mouse for new projects.

I agree, infact I'd start teaching OO perl as Moose/Mouse and only begin
discussing the older way (as expressed in the OO Perl book)
when someone wants to learn more about Perl OO internals.

--
ispy++

Re: To learn perl... [was: decline and fall of modperl?]

--001636c5bb89bd4ad2046609f7bf
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Mar 26, 2009 at 6:29 PM, Joel Bernstein wrote:

>
> On 26 Mar 2009, at 13:21, Rolf Banting wrote:
>
>> Fair enough Simon. I would recommend you look at the Cookbook too - it has
>> recipes for everything from iterating through a hash to web automation.
>>
>> http:/SNIP/perl/cookbook/
>>
>
> Why would you do that? I'm sure you realise that a Ukrainian mirror of the
> first edition is unlikely to be officially sanctioned.


Didn't occur to me. Too busy to think to check. I apologise
*unreservedly*if there is anything untoward about the link.


> You like the book so much that you want to screw its authors by linking to
> a pirated copy stolen from the Perl CD Bookshelf?

I'm sure your mother taught you better.


!!!!!!!!!!!!!!!!!!!!!!!!


> http://oreilly.com/catalog/9780596003135/index.html
> Is the correct link, and it's for the Second Edition rather than the First.
> Which is newer and much better.
>
> Please don't encourage people to steal anybody's work, let alone the work
> of such excellent community members (who have given so much to Perl) as gnat
> and tchrist!
>
> I'm quite happy to accept that you might have made an honest mistake in
> selecting that URL as an example, but I think it's important to note that
> it's not a reasonable example and IMO one that cannot be accepted here.
>
> /joel
>

--001636c5bb89bd4ad2046609f7bf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

lid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">You =
like the book so much that you want to screw its authors by linking to a pi=
rated copy stolen from the Perl CD Bookshelf?

204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm sure your=
mother taught you better.=A0

rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

blank">http://oreilly.com/catalog/9780596003135/index.html

Is the correct link, and it's for the Second Edition rather than the Fi=
rst. Which is newer and much better.



Please don't encourage people to steal anybody's work, let alone th=
e work of such excellent community members (who have given so much to Perl)=
as gnat and tchrist!



I'm quite happy to accept that you might have made an honest mistake in=
selecting that URL as an example, but I think it's important to note t=
hat it's not a reasonable example and IMO one that cannot be accepted h=
ere.




/joel

Re: [m_p] Re: decline and fall of modperl?

From: "Walter Pienciak"
> I usually lurk on this list, but I could not disagree more with
> this assertion that perl is somehow harder to learn.

This might be because you are thinking to the american or western european
market.
But think about those many programmers that don't know english, and don't
have books translated in their languages, but do have very many books for
Java, PHP and DotNet translated.
Do you still think that Perl is so easy to learn?

> I'm not a language ideologue; I use Perl because it lets me get
> my job done with a minimum of baggage -- and because it's proven
> itself: it doesn't get in the way of getting actual work done.

I also use perl for this reason, but as I said, we, the perl programmers
have good reasons for loving perl, so we are not very interesting in this
discussion.
What would be more interesting would be to find why the new kiddies that
intend to learn programming are not extraordinary excited about Perl, but
love more PHP, Ruby, Python.

> I've not come across a language that is better at allowing
> someone to be quickly productive in it. I believe that's due to
> the flexibility of syntax that we all know. Declarative,
> object-oriented, sub main(), spaces/tabs, style -- hey, it's all
> good. Vi, emacs, pico, ex, Notepad, Eclipse -- whatever. Just
> pick up your favorite environment and go to work!

This is also true for C#, Java, PHP, Python, Ruby, but some of them have a
nicer and powerful OOP, and they can be also used with Notepad and
executed/compiled in a command line, but some of them also have better
editors.

> My experience is that a person's early Perl work is often
> structured and coded in ways that map closely to the person's
> background in other languages -- and leans heavily on constructs
> already familiar to them -- but that as time goes by, a "more
> Perlish" flow develops as they learn more details of the
> language. The Perl community is also an open one, and that
> culture is desirable to me as something consistent with our team
> culture.

Too bad that Perl's dependent on more other things like C code, because many
cpan modules use C code, and it is hard to find their bugs if they can't
pass all the tests. Perl also requires Unix knowledge even for those who use
it only under Windows.

There are very many programmers that know only to make programs with PHP,
without even knowing how to configure crontab, and of course, without
knowing C or too many things about Linux. They just know how to upload their
code on an FTP site, and they can do their job fine. If a perl programmer
would know just perl, and how to upload the files on an FTP server... I
don't think that programmer will be able to do something useful.
This is not an advantage of Perl. Perl is targeted to more inteligent
programmers so for the others it is not a very good tool.

> Is it all things for all folks? Oh, hell no. If I had to lead a
> multi-hundred-person team of widely varying or potentially
> dubious experience -- perhaps on another continent -- coding a
> single large project . . . well, at that point the flexibility
> arguably becomes an issue. If you need to rigoriously control
> the minutiae to keep a large team and its output consistent --
> variable and method naming SHALL be done this exact way, for
> example -- or your CIO religiously/blindly follows some research
> firm that says this or that is "enterprise class," well, okay.

Aha. Well, very many (if not the majority) of the software companies in my
country do outsourcing for other software companies from USA and other
western european countries.
They need to cooperate with the branches of those american companies from
all over the world. They need to work in wide temporary teams with people
they don't know, that have another native language, and make sure they all
create a good product.
I think it could be very hard to promote Perl in those companies.

Octavian

Re: decline and fall of modperl?

This is a multi-part message in MIME format.

------=_NextPart_000_009A_01C9AE5C.A3138700
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

From: Rolf Banting=20
> Functions are first class citizens in Perl - so you get functional =
programming built in. You don't in Java.

Even the newer perl modules on cpan started to use OOP, and I guess =
this is because OOP is better, even though under perl it usually makes =
the programs run slower.
I guess that today there are no many students that are taught in =
schools that the functional type of programming is good...

> How are standards of OO quantified and compared?

Simple. They should follow the "modern" standards, standards made by =
those who have the power to promote their way - Sun, Oracle, IBM, =
Microsoft.
This is because if a student learns C#, and learns Java, he will find =
easier to learn an OOP style similar to that from Java than a way like =
the one used in Perl.

And anyway, for the beginners, this is not a big problem. The =
biggest problem is that perl is harder to learn. The programmers might =
want to learn a language for a year, and get a job, and after this they =
hope that they will find time to learn the chosen language better while =
they have a job.
Harder to learn than what? Is there any evidence for this?
Yes. Most PHP programmers I know, that also tried to learn Perl told =
me that PHP is more easy to learn and to use.

We could say that perl would be really great for these days if we =
could say about it something like:
- It is the most easy to learn language even by the most stupid =
programmers.
It is easy to learn!=20


The core language, yes, but in order to prove its advantage, the =
programmer also needs to know how to use hundreads of CPAN modules, and =
with all those modules, it is much harder to learn, because it requires =
to learn how to get them, how to compile them, how to fix the errors =
they give when trying to install them, and finally the programmer will =
find that some of the good and recommended perl modules from CPAN aren't =
even portable under Windows.
Without the CPAN modules, perl is much lower level than PHP, and =
it isn't so productive anymore.

> There are very many recent books that teach Perl.
Why is "recent" important? The language features haven't changed much =
so why would the learning resources?=20


Because Catalyst is very fast changing, DBIx::Class the same, =
HTML::FormFu the same, CGI::Application the same, because Moose =
appeared, but there are no very many books that talk about them (or =
other modules).

There are however very many perl books that teach how to use =
CGI.pm, how to print "Content-Type: text/html\n\n";... and of course =
that if a beginner programmer will start to read them, he will think =
that perl is obsolete, even though it is not true.

- There are important other software made in Perl which are used =
much these days, like a mailing list manager, a web server, financial =
charting software, stock exchange trading applications, etc.
I know of perl CORBA applications that have been responsible for =
charging literally millions of real-time short messages in telecomms =
networks in Latin America.=20


From the point of view of students, this is very little relevant.
Is that company very well known? Does it has advertising on MTV? =
or at least CNN to be well known in the entire world?

Because if it is not, the students will see that some pages from =
google.com have an url that ends with .py and not .pl, and this means a =
lot for them and for the language they will choose.

Perl is great, but I think it will remain a niche language for a =
long period, even though we know that we can do everything with it. The =
truth is that we can't do really everything with it. There are =
applications made in Java that do annimation, graphic games, search =
engines, and many other things that we can't do only by using perl, =
without C or other languages.

Octavian

------=_NextPart_000_009A_01C9AE5C.A3138700
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable



charset=3Diso-8859-1">

Re: decline and fall of modperl?

From: "Joel Bernstein"
> - It is the most easy to learn language even by the most stupid
> programmers.

> I'd rather it were optimised for competent programmers. Sorry, I just
> don't see the value here. Stupid programmers are part of the problem.

I don't understand. What is the problem? That perl is useless for most
programmers because they are stupid?
The majority of programmers will be always less intelligent than those few
very inteligent ones.
Why it is bad that a language like PHP is more useful for more programmers?

> - It can create portable programs that can run everywhere, under Windows,
> Mac, Linux, shared hosting web sites that don't offer root and shell
> access...

> Perl programs are typically extremely portable, and perl runs on many
> more platforms than those you have listed. Shared hosting websites ought
> to be able to run Perl applications uploaded with a local::lib tree and
> so on.

I've tried to install some perl modules under Windows and I couldn't do it.
Then I found that they can't run under Windows. This doesn't mean
portability.
I have also tried to use Local::Lib but very many modules use to give errors
when trying to install them using -MCPAN -e ... and I didn't know how to use
this syntax but also use "force" like in
cpan> force install ModuleName
(Please tell me if you know how)

> - The source code of the programs can be hidden.

> No. This issue needs to be solved through contractual means. There are
> options to limit the ease with which your code can be recovered but they
> don't raise the bar very far. And more importantly they aren't solving
> the right problem. If you can't make money on new development, support
> contracts, training etc, maybe your business model is flawed.

You don't know how things work in other countries.
Nobody cares about a contracts for software licences in my country.

> - Perl is chosen by bigger companies like IBM, Oracle, Microsoft, Sun,
> Yahoo, Google, SAP.

This one's solved. More than half of those companies are publicly
documented to use Perl. Possibly not to support their core products,
but still, Perl.

Maybe, but who knows this?
The target audience should be the students, the future possible perl
programmers.

> - The popular sites like Twitter, Digg, Facebook, MySpace, Wikipedia, are
> powered by perl.

There are popular sites like BBC News, Vox, Ticketmaster, Shopzilla,
Takkle, BBC iPlayer, Editgrid, IUseThis, YouPorn, MighTyV and so on.
Mostly using Catalyst. Some of those definitely exist in the "web 2.0"
space you seem to be focussing on. Is there some cognitive dissonance
here on my part, in that the sites you list are mostly particularly
news-worthy ones? I think the list I put out is pretty impressive and
is certainly not exhaustive.

Yes, as I said, if we want perl to be really the best for most programmers,
it would be important to promote it for the new programmers, and they are
the teenagers, and those sites target to them.
For them perl shouldn't appear as classic mahogany furniture, but as cool
nice coloured plastic, because otherwise it would appear as old and boring
while RoR and Python will sound much better.

> - There are important other software made in Perl which are used much
> these days, like a mailing list manager, a web server, financial charting
> software, stock exchange trading applications, etc.

Not sure how to address these. I've seen a MLM in Perl (Siesta) but
people didn't want to hack on it. Mailman works well enough for most
people's needs.

Oh yes, but it is made in Python, and some programmers might find that even
in the field of mailing list managers we passed from Majordomo made in perl
to Mailmain made in Python... maybe because Python is better... not?

There's also good charting support on the CPAN, etc. Can you give
examples of open source financial analysis, stock trading etc
applications in other languages?

Why should they be open source? Perl could be also used in commercial
proprietary programs, and unfortunately in some countries it is very hard to
earn money from open source.
This is why I said that the software companies prefer Java, because nobody
considers that it is something bad if a program made in Java is not open
source.

Octavian

Re: decline and fall of modperl?

This is a multi-part message in MIME format.
--------------080209070608070107010906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Octavian Râsnita wrote:
> *From:* Rolf Banting
>
> > Functions are first class citizens in Perl - so you get
> functional programming built in. You don't in Java.
>
> Even the newer perl modules on cpan started to use OOP, and I guess
> this is because OOP is better, even though under perl it usually makes
> the programs run slower.
Perl's speed, even under oop, is good enough. OOP makes the libraries
easier to maintain and extend. You should well be an advocate of
good-enough - thats what the php programmers are all about, right?
>
> > How are standards of OO quantified and compared?
>
> Simple. They should follow the "modern" standards, standards made by
> those who have the power to promote their way - Sun, Oracle, IBM,
> Microsoft.
> This is because if a student learns C#, and learns Java, he will find
> easier to learn an OOP style similar to that from Java than a way like
> the one used in Perl.
I can't believe you would say that the particular syntactical constructs
used in the object oriented declaration is even slightly relevant to the
usability of the language. saying 'package' instead of 'class'? Saying
'use' instead of 'import'? I'm agog. Any language transition involves
learning new syntactical constructs for the new environment you're in.
And thats the only real difference between The Java/C# 'style' and perl,
is it not? THe keyword syntaxes? As for design patterns, perl does
them with fewer hoops than the other languages - which is what a
learning student needs to learn.

> And anyway, for the beginners, this is not a big problem.
> The biggest problem is that perl is harder to learn. The
> programmers might want to learn a language for a year, and
> get a job, and after this they hope that they will find
> time to learn the chosen language better while they have a
> job.
>
> Harder to learn than what? Is there any evidence for this?
>
> Yes. Most PHP programmers I know, that also tried to learn Perl told
> me that PHP is more easy to learn and to use.
And C is easier to use than C++, but you don't see anybody going around
saying that they should use C to write enterprise applications these days.

Unfortunately I think some are trying to be written in php.
>
> > There are very many recent books that teach Perl.
>
> Why is "recent" important? The language features haven't changed
> much so why would the learning resources?
>
> Because Catalyst is very fast changing, DBIx::Class the same,
> HTML::FormFu the same, CGI::Application the same, because Moose
> appeared, but there are no very many books that talk about them (or
> other modules).
The moment a fast-changing thing is documented, the documentation is out
of date. Its a fundamental problem with dead-tree editions of
anything. I'm not surprised that there aren't books on these things.
Mostly because the documentation is readily available online and
anything written is obsolete before it hits the presses.
> Perl is great, but I think it will remain a niche language for a long
> period, even though we know that we can do everything with it. The
> truth is that we can't do really everything with it. There are
> applications made in Java that do annimation, graphic games, search
> engines, and many other things that we can't do only by using perl,
> without C or other languages.
Yes, we cannot do everything with perl. But that is okay. What is
important to remember is what we CAN do with perl. Even when you have a
high-performance graphical processor module written in C/C++/Java, the
business rules, glue, and associated logic that is not fine-grained
performance critical are best implemented in a scripting language just
like Perl.

Implementing your application in C++ because you need *some*
fine-grained performance critical code is, in my experience, foolish.
Yes, implement your critical code in a tight language. But when most of
the application just comes down to glue, field name translation, and
rules checking - this is better scripted than coded in a compiled
language. I've wasted tens of thousands of dollars of my employers time
compiling and debugging because of the application's shortsighted
architecture put many of the business rules in C++ instead of a script
like perl! (it was all the worse because at an arbitrary divider, some
of the rules WERE in a not-quite-perl like configuration language - if
they had taken it all the way a job of months would have taken weeks)

It was quite a mind-blow when I realized that the c++ application that
took a gig of memory *per process* to run that I and my coworkers
struggled with making behave for so long came down to something that
could have been implemented with daemontools, a WSDL checker module,
DBI::Oracle, and a passel of business rule implementation classes.
(Turns out the windows on that building don't open...)

Playing nicely with other applications is merely a matter of interface
definition and integration testing. Well defined specifications and a
perl module service can interact with any other. Being able to work
with your application because it doesn't take 40 minutes to compile a
SQL typo fix is not priceless, but its worth a heck of alot.

David


--------------080209070608070107010906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit








Octavian Râsnita wrote:

type="cite">

From: title="rolf.b.mr@gmail.com" href="mailto:rolf.b.mr@gmail.com">Rolf
Banting

style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

> Functions are first class citizens in Perl - so you get
functional programming built in. You don't in Java.

type="cite">
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

> How are standards of OO quantified and compared?

type="cite">
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

And anyway, for the beginners,
this is not a big problem. The biggest problem is that perl is harder
to learn. The programmers might want to learn a language for a year,
and get a job, and after this they hope that they will find time to
learn the chosen language better while they have a job.

type="cite">
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">

> There are very many
recent books that teach Perl.

style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

type="cite">

Perl is great, but I think it will
remain a niche language for a long period, even though we know that we
can do everything with it. The truth is that we can't do really
everything with it. There are applications made in Java that do
annimation, graphic games, search engines, and many other things that
we can't do only by using perl, without C or other languages.

[OT] Advocacy (was Re: decline and fall of modperl?)

--0-593029566-1238102407=:44648
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Could we PLEASE move this lovely conversation to the=0Aadvocacy@perl.apache=
..org mailing list? We have an=0Aentire mailing list dedicated to baloney o=
f this sort;=0Aplease use it so the rest of us trying to provide this=0Alit=
tle community with meaningful software and support=0Adon't have to wade thr=
ough it. =0AThanks! _____________________________ ___=0AFrom=
: David Ihnen =0ATo: Octavian R=E2snita ail.com>=0ACc: modperl =0ASent: Thursday, March 26=
, 2009 5:10:58 PM=0ASubject: Re: decline and fall of modperl? Octavia=
n R=E2snita wrote: =0A =0AFrom: Rolf=0ABanting =0A> Functions are first cla=
ss citizens in Perl - so you get=0Afunctional programming built in. You don=
't in Java. Even the newer perl modules on cpan=0Astarted to use OOP, =
and I guess this is because OOP is better, even=0Athough under perl it usua=
lly makes the programs run slower.=0APerl's speed, even under oop, is good =
enough. OOP makes the libraries=0Aeasier to maintain and extend. You shou=
ld well be an advocate of=0Agood-enough - thats what the php programmers ar=
e all about, right? > How are standards of OO quantified and compared?=
Simple. They should follow the=0A"modern" standards, standards made b=
y those who have the power to=0Apromote their way - Sun, Oracle, IBM, Micro=
soft.=0AThis is because if a student learns=0AC#, and learns Java, he will =
find easier to learn an OOP style similar=0Ato that from Java than a way li=
ke the one used in Perl.=0AI can't believe you would say that the particula=
r syntactical=0Aconstructs used in the object oriented declaration is even =
slightly=0Arelevant to the usability of the language. saying 'package' ins=
tead of=0A'class'? Saying 'use' instead of 'import'? I'm agog. Any langu=
age=0Atransition involves learning new syntactical constructs for the new=
=0Aenvironment you're in. And thats the only real difference between The=
=0AJava/C# 'style' and perl, is it not? THe keyword syntaxes? As for=0Ade=
sign patterns, perl does them with fewer hoops than the other=0Alanguages -=
which is what a learning student needs to learn. =0AAnd anyway, for=
the beginners,=0Athis is not a big problem. The biggest problem is that pe=
rl is harder=0Ato learn. The programmers might want to learn a language for=
a year,=0Aand get a job, and after this they hope that they will find time=
to=0Alearn the chosen language better while they have a job.=0AHarder to l=
earn than what? Is there any evidence for this?=0AYes. Most PHP=0Aprogramme=
rs I know, that also tried to learn Perl told me that PHP is=0Amore easy to=
learn and to use.=0AAnd C is easier to use than C++, but you don't see any=
body going around=0Asaying that they should use C to write enterprise appli=
cations these=0Adays. Unfortunately I think some are trying to be writ=
ten in php. > There are very many=0Arecent books that teach Perl.=0AWh=
y is "recent" important? The language=0Afeatures haven't changed much so wh=
y would the learning resources? Because Catalyst is very fast=0Achang=
ing, DBIx::Class the same, HTML::FormFu the same, CGI::Application=0Athe sa=
me, because Moose appeared, but there are no very many books that=0Atalk ab=
out them (or other modules).=0AThe moment a fast-changing thing is document=
ed, the documentation is=0Aout of date. Its a fundamental problem with dea=
d-tree editions of=0Aanything. I'm not surprised that there aren't books o=
n these things. =0AMostly because the documentation is readily available on=
line and=0Aanything written is obsolete before it hits the presses. Pe=
rl is great, but I think it will=0Aremain a niche language for a long perio=
d, even though we know that we=0Acan do everything with it. The truth is th=
at we can't do really=0Aeverything with it. There are applications made in =
Java that do=0Aannimation, graphic games, search engines, and many other th=
ings that=0Awe can't do only by using perl, without C or other languages.=
=0AYes, we cannot do everything with perl. But that is okay. What is=0Aim=
portant to remember is what we CAN do with perl. Even when you have=0Aa hi=
gh-performance graphical processor module written in C/C++/Java,=0Athe busi=
ness rules, glue, and associated logic that is not fine-grained=0Aperforman=
ce critical are best implemented in a scripting language just=0Alike Perl.=
Implementing your application in C++ because you need *some*=0Afine-g=
rained performance critical code is, in my experience, foolish. =0AYes, imp=
lement your critical code in a tight language. But when most=0Aof the appl=
ication just comes down to glue, field name translation, and=0Arules checki=
ng - this is better scripted than coded in a compiled=0Alanguage. I've was=
ted tens of thousands of dollars of my employers=0Atime compiling and debug=
ging because of the application's shortsighted=0Aarchitecture put many of t=
he business rules in C++ instead of a script=0Alike perl! (it was all the =
worse because at an arbitrary divider, some=0Aof the rules WERE in a not-qu=
ite-perl like configuration language - if=0Athey had taken it all the way a=
job of months would have taken weeks) It was quite a mind-blow when=
I realized that the c++ application that=0Atook a gig of memory *per proce=
ss* to run that I and my coworkers=0Astruggled with making behave for so lo=
ng came down to something that=0Acould have been implemented with daemontoo=
ls, a WSDL checker module,=0ADBI::Oracle, and a passel of business rule imp=
lementation classes. =0A(Turns out the windows on that building don't open.=
...) Playing nicely with other applications is merely a matter of inter=
face=0Adefinition and integration testing. Well defined specifications and=
a=0Aperl module service can interact with any other. Being able to work=
=0Awith your application because it doesn't take 40 minutes to compile a=0A=
SQL typo fix is not priceless, but its worth a heck of alot. David=0A=

--0-593029566-1238102407=:44648
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

ad>